Comments 242
Пока это мне не понятно, поэтому мое мнение — развивать его не стоит.
Кстати цель — существительное. То есть «развитие языка» — это не цель.
Интерес — цель.
Настроение — цель.
Знание — тоже цель.
Скорее всего — настроение.
В отличие от многих бредятин в этих ваших хабрах данная бредятина статья положительное доставляет.
Автору — пешыистчо респект!
Кстати цель — существительное. То есть «развитие языка» — это не цель.
Интерес — цель.
Настроение — цель.
Знание — тоже цель.
Слово "развитие" — тоже существительное, не?
Слово «развитие» — тоже существительное, не?
Тоже верно. Формально это так. Само слово «развитие» обозначает нематериальный объект, оно обозначает больше действие, некий процесс.
А лучше избегать процессов и сложных абстрактных определений в формулировке цели.
Например, «расширение рынка сбыта» — это плохо сформулированная цель. Ее трудно параметризировать. Да и рынок можно не только расширять, это один из методов или способов увеличения продаж.
Цели поменьше: возможность написания кода на русском языке, и как некое следствие: интерпретатор можно доработать так, что одну и ту же программу, выдающую один и тот же результат, можно написать и на русском, и на английском языке (чтобы утихомирить интернациональное сообщество).
Интерес: в будущем просто и наглядно запрограммировать на РЯП ЛЮБОЙ алгоритм: сжатие данных, вычисление MD5, шифрование информации, обработка двумерной графики (а потом и n-мерной).
Расширение: написание интерпретатора РЯП под DOS, на Java для сотового телефона, на Linux.
И я бы даже сказал, как бы это бредово ни звучало, что я сам ещё не могу до конца сформулировать все цели написания языка, который я придумываю. То есть эти цели будут конкретно формулироваться в процессе улучшения языка.
простая среда разработки
Любой случайно взятый редактор для txt лучше среды, которую можно быстро написать. Для нормальной работы с языком нужен консольный интерпретатор, который можно было бы запустить не открывая лишних окон.
Отсутствие возможности редактировать код в любом удобном текстовом редакторе, а потом запустить его, не закрывая редактор, — большой недостаток многих языков.
(камраду ниже: блестяще! ХРЯК-ХРЯК и в продакшн! определенно нам этого не хватало)
Хороший Русский Язык Кодирования
СВИНЯРА
Совершенно Великолепный И Новый Язык Русских Алгоритмов
А это уже тянет на импортозамещение.
"Хороший Универсальный Язык Кодирования Хороший Универсальный Язык Кодирования для производственных систем"
Хороший Универсальный Язык Кодирования сделал мне пятничный вечер! :-DDD
В университете у нас был курс теории языков программирования (ТЯП). Вот там-то РЯП был бы точно к месту!
Очередной пост о создании нового языка программирования без:
- задачи
- обоснования необходимости
- примеров конструкций
- примеров кода
- исходников
Необходимость — в том, чтобы писать на русском языке, а не на английском.
Языков с ключевыми словами на русском языке больше одного. И это не говоря о том, что можно легко сделать соответствующий форк существующего языка с латиницей.
Впрочем, школьникам все равно придется столкнуться с английским рано или поздно, так может лучше рано?
Примеров кода приведено достаточно в архиве, и примеров конструкций.
Ненене. Никаких архивов. Есть пост, из которого можно было бы брать цитаты и обсуждать их. А архив качать неизвестно откуда? Спасибо, нет.
Исходники пока закрытые.
Ну и зачем? Особенно прекрасно это сочетается с "свободно скачивайте и распространяйте".
Необходимость — в том, чтобы писать на русском языке, а не на английском. Стало быть, например, учить школьников — гораздо проще.
Рекомендую поискать англоязычные исследования на эту тему.
По-моему это наоборот мешает, отделить привычные бытовые понятия от того, что слово является ключевым для компилятора. Т.е. будут относиться к компилятору как человеку. На практике это может привести к тому что вместо команды «покажи», дети будут пробовать вбивать команды «напечатай», «расскажи» и т.п.
На данный момент есть интерпретатор РЯП, и нет компилятора.
для существующей команды «показать» можно добавить все эти аналоги: «покажи», «напечатай», «расскажи».
Все? Еще и с поправкой на знание детьми русского языка? Вам придется решать задачу NLU, причем в полном объеме.
В итоге проблема английских букв меняется на новую проблему восприятия.
Великий и могучий настолько могучий это заколебётесь для каждой команды прописывать аналогиТогда уже сразу пилить поддержку всех суффиксов и окончаний, падежей, родов, чисел и т.д. А синонимы из специального словаря доставать.
здарова
зафигачь мне массив
и шоб по красоте
харе э
Не спора ради, а как пример подтверждающий комментарий выше.
Я когда учился в школе, у нас был такой "язык" — кумир робот. Можно было управлять роботом с помощью команд "влево", "вправо", "вверх" и "вниз" и т.д. Очень часто мои одноклассники писали "вбок" и не понимали что же не так в их программе.
Когда я вижу подобные упражнения в прекрасном, мне каждый раз становится интересно, откуда у людей возникает эта неспособность строить логические цепочки сложнее двух элементов
Все нормальные языки программирования основаны на латинице и английском не потому что это заговор рептилойдов, а потому, что весь мир, объективно, читает латиницу и худо-бедно говорит на английском, так что это просто универсальнее, чем пытаться впихнуть очень локальные язык и алфавит в, объективно, довольно глобальную тему IT
Тогда почему было не перевести любой существующий язык?
То, что Вы создали сейчас — очень плохо и не подаёт надежд.
Мне больше всего нравится Паскаль из-за относительной простоты. И никогда не нравился Си из-за своей сложности, в том смысле, что любой алгоритм, любую программу можно написать проще на том же Паскале, не прибегая ко всяким изощренным конструкциям Си. Больше всего я программировал на Паскале и на Си. В меньшей степени — на Ассемблере, Джаве и Бейсике.
Лично я питаю надежды к РЯП, если бы я не возлагал бы никаких надежд (пусть мои надежды воспринимаются людьми как мои сугубо субъективные надежды), я бы просто не выдумал РЯП. То есть при выдумывании РЯП для меня была важна философия языка программирования, а технические вопросы — уже второй вопрос. На данный момент на РЯП можно прекрасно запрограммировать всякие математические вычисления (синус, корень числа, число ПИ и т.д.). Разумеется, раз язык интерпретируемый, то нет никакой речи о быстром выполнении кода. Но я изначально не принимал во внимание быстродействие. Так как в юности воспитался на том же аналоге ПЭВМ «Радио86-РК» — «Партнёр 01.01 ВЦ».
философия языка программирования
Так описали бы сперва её. По постулатам и следствиям, как у Аристотеля. И потом, убедившись в её внутренней непротиворечивости — писали язык.
Кстати, вы на языке микрокалькуляторов (ЯМК) программировали?
Но в SoloTable по сравнению с РЯП наоборот, программы пишутся латинскими буквами, каждая буква — это команда. Скачайте архив, запустите Сотейник, и почитайте описание языка на вкладках «Readme».
создать максимально простой язык программирования
Приведите критерий "простоты". Формальный и объективный, а не "мне кажется, что так проще".
Мне больше всего нравится Паскаль из-за относительной простоты. И никогда не нравился Си из-за своей сложности, в том смысле, что любой алгоритм, любую программу можно написать проще на том же Паскале, не прибегая ко всяким изощренным конструкциям Си.
Но ведь… Си проще паскаля. В паскале дикое количество вариантов массивов, массивы, индексируемые типом-диапазоном или перечисляемым типом, или каким-нибудь short или byte, множества, строки, типы-диапазоны, цикл for в двух направлениях, каждый тип указателя нужно объявлять, 3 типа передачи аргументов в функцию, какие-то свои вещественные типы real, extended; объектный тип, отдельный синтаксис для аргументов read[ln]/write[ln], цикл repeat-until не имеет begin-end и продолжается условии false, а не при true, как while-do, etc. А в си просто указатели нормально сделаны, присваивания возвращают результат, цикл for более универсален, битовые поля иногда есть, да функции могут принимать переменное число аргументов. Скобочки не в счёт — {} не менее читаемы, чем begin end.
Возьмите лучше Python 3. Или даже C. Это хорошие, простые, распространённые языки, с ними больше шансов на успех.
Переменные не надо объявлять, так как при первом обнаружении переменной в листинге программы интерпретатор автоматически создаст с таким именем переменную типа Double (вещественное число).
Дадада.
color = 'red'
print(colour)
Удачи.
Имя переменной можно сокращать.
Интерпретатор сам определит, какую переменную из объявленных имели в виду.
Для учебного языка — даже хорошо. Чтобы ПРОЧУВСТВОВАТЬ, чем явные объявления лучше неявных.
Я с BASIC начинал. Сперва спотыкаешься об подобную хрень, потом сам прописываешь OPTION EXPLICIT и понимаешь, зачем в языке ограничения.
Ведь Double — это не только вещественное число, но и целое число! И если вы не используете строки, значит используете числа, а тип Double покрывает все нужды (если разрядность не ограничивает работу конкретного алгоритма).
Кстати, когда реализую механизм массивов, то запилю длинную арифметику.
вот в таком цикле
Для Инд Тип Double=1.1 По 2 Шаг 0.1 Цикл
ВыводСтроки «Инд = „+Инд
КонецЦикла
на экран консоли не будет выведено число 2, т.к. в результате накопления микроскопической ошибки на каждой итерации, значение переменной цикла слегка превысит значение 2 и последняя итерация выполнена не будет.
лучше используйте Decimal
Double — это не только вещественное число, но и целое число!Целые числа double представляет скажем так не очень. До степени когда 1+2 != 3, что усложняет объяснение основ программирования школьникам.
Нет, целые как раз представляет хорошо. До 2^56.
Можете привести пример, когда операция над целыми в указанных пределах приводит к погрешности?
пример на C#
for (double i = 1.1d; i <= 2d; i = i+.1d) {
Console.WriteLine(i);
}
число 2 не будет выведено в консоль, хотя ОЖИДАЕТСЯ, что оно будет выведено…
Ну, простите, когда я работаю с плавающей точкой, я ОЖИДАЮ что существует погрешность. Причём, не только погрешность вычислений, но и погрешность исходных данных.
А тот, кто не ожидает — сам себе злобный буратино.
Смотря что за язык. Погрешность результата вычислений измеряется в знаках. Десятичные знаки — больше, чем двоичные. Соответственно при приближенных вычислениях погрешность десятичного формата будет расти быстрее, чем двоичного.
Собственно о чём я говорил: абсолютно точные исходные данные бывают только в школе и в деньгах.
Если мы считаем что-то, кроме денег, у нас на входе будут результаты измерения — априори содержащие погрешность.
Ведь Double — это не только вещественное число, но и целое число! И если вы не используете строки, значит используете числа, а тип Double покрывает все нужды
И вот что бы не взять decimal
, у которого нет проблем с округлениями?
Для учебного языка — даже хорошо
Это смотря чему учить.
Учебные языки нужны для того, чтобы учить с нуля. Написать прямо в код "5 CLS" и увидеть результат.
Для обучения тех, кто уже знает основные идеи, типа ветвления и циклов, чему-нибудь более-менее сложному годится уже любой популярный язык.
Учебные языки нужны для того, чтобы учить с нуля.
Чему учить-то? Какая задача?
Ознакомить учащегося с тем, что такое язык программирования, какие приёмы управления потоком выполнения он предоставляет, и как применить его к практическим задачам. Научить не бояться вносить изменения в программу, и адекватно реагировать на появление ошибок компиляции и выполнения.
Зачем? Цель этого всего какая?
Такая же, как при обучении математике. Чтобы человек не был нулём, и мог в дальнейшем самостоятельно изучать другие языки.
То есть вы предлагаете считать, что программирование нужно настолько же, насколько и математика, и учить исходя из этого допущения?
А вот интерпретатор РЯП написать под DOS уже на порядок легче.
То есть DOS, Linux, Java, промышленные контроллеры — это будущие кандидаты на реализацию интерпретатора РЯП.
А зачем писать интерпретатор Си под DOS или BIOS, если можно скомпилировать программу на Си для выполнения под DOS (и, думаю, под BIOS тоже)?
Я понимаю, что пятница уже вовсю идёт, но не до такой же степени!
Логические операции и условные операторы таки_да, таки_нет, а_вдруг_если будут?
да_нет
а_если_найду ...
«иди на ...»
Тем не менее это оператор есть и в Си и в Паскале. И если цивилизованный программист вполне может отказаться от их использования, то всякие автоматические Нечто-Паскаль трансляторы без него не обходятся
Стоп-стоп-стоп!
А как же break? Это ведь именно "иди на..." или "иди в...", в общем "катись отседова!"
начало
какой-то код
если остаток
цикл = 0
цикл цикл
… а если это надо сделать не последней инструкцией в цикле? Все остальное снова в если
заворачивать?
если
заворачивать.… то есть каждый раз, когда надо сделать break
, мы увеличиваем вложенность на уровень.
Но зачем?
А зачем нужен "простой" язык, на котором сложно писать, особенно учитывая, что вы этот язык предназначали, если вам верить, для обучения?
Например, брейнфак можно изучить на 100% за несколько часов.
РЯП можно изучить за несколько дней, Паскаль за 1 месяц, Си за 6 месяцев.
А потом предлагают человеку написать алгоритм на каждом языке. За какое время он напишет его на каждом языке?
мне просто писать на РЯП.
Это не удивительно, это же ваша разработка.
У каждого языка существует время, за которое обучаемый может изучить предлагаемый ему язык на определенное кол-во процентов.
Сравнивать в процентах бесполезно, потому что у языков разный объем функциональности. Сравнивать надо в выученном объеме функциональности.
РЯП можно изучить за несколько дней, Паскаль за 1 месяц, Си за 6 месяцев.
Я не знаю про Паскаль и Си, я знаю про C#. Заметим, я пишу на C# лет пятнадцать, и все равно не могу сказать, что знаю его на 100%, но не суть. Но я готов сказать, что изучить C# в объеме той функциональности, которую — по вашему посту — предлагает РЯП можно за то же время (а может быть и быстрее), что и РЯП.
За какое время он напишет его на каждом языке?
А понятия не имею. Но уверен, что будет заодно зависеть и от алгоритма.
Например, брейнфак можно изучить на 100% за несколько часов
Секунд.
РЯП можно изучить за несколько дней
На чтение спеки по ЯМК у меня примерно 36 часов ушло. Что, в общем, обычное время для чтения спеки. Программировать вычисления можно начинать сразу.
Правда, редактор на борту МК-161 прямо скажем, никакой.
Начал разработку русского языка программирования.
В русском языке обычно несколько иная структура предложений...
Недостаточно масштабно.
Отрекаемся от логических функций "И, ИЛИ, НЕ". Вместо них берём "НУ, МОЖЕТ, ЯХЗ".
На этой базе строим свою смехотехнику, в которой ошибка будет неотличима от штатного поведения системы. Это же спасёт нас от ревизии.
И просим 100500 олимпиардов на замещение архитектуры прошлого тысячелетия.
Главное полностью отказаться от четкой логики, от классических true/false.
На этой базе строим свою смехотехнику
Очепятка от бога. Ну или не очепятка…
А як же ж.
† — ставится в конце программы, означает "ну, с богом..."
Нет духа старого Кащенко okante.narod.ru/D
Переменные не надо объявлять — плюсы и минусы яву со строгой типизацией данных.
Собственно ядро языка это наверное 5%. Остальную популярность ему обеспечивает наличие готовых библиотек и фреймворков.
В принципе написание своего парсера выражений или семантического разбора замечательная практика для студента. вполне тянет на тему диплома.
А вот дальше чем хобби в 99.9999% не пойдет.
Операторы нечеткой логики Авось и Небось будут к месту
Правильно ли я понимаю, что для отладки можно в тело цикла вставить оператор
показать член
?Цикл цикл — 1 цикл цикл! Цикл
И пусть интерпретатор сам догадается, что имелось в виду.
А что мешает применять для этих целей другие существующие языки программирования?
уже давно ноет о том, что вот у англоязычных авторов есть Inform
Так это специализированный язык. Его надо отдельно разрабатывать, именно под эти задачи.
А если вам надо просто не переключать раскладку, так уже ж есть языков с кириллицей.
Просто надо именно так задачу и поставить (и, возможно, просто договориться с inform о разработке перевода). А автор этого языка уже явно сказал, что на другие задачи ориентируется.
Си и Паскаль уйдут, Питон утонет, Яву скурят!Такие себе цели. Ну да ладно. [машет рукой]
ЕСЛИ КОНЕЦ ЦИКЛ
Цикл(пока, до)…
1С видел раз в жизни — такие же чувства.
Давайте тогда уж
#define коли if(
#define пущай ){
#define ежели }else if(
#define либо }else{
#define аминь }
#define покуда while(
#define твори do{
#define доколе }while(
#define буде );
#define откель for(
#define ступай goto
#define вон exit
#define
покуда а мене 10 пущай а стане а да 1 аминь
// твори а стане а без 1 доколе а поболе 0 буде
Согласен, что это такое российское импортозамещение «прямо в лоб», но лично мне это кажется вполне актуальным и даже конкурентоспособным в потенции.
В перспективе на доработанном РЯП можно будет написать ЛЮБОЙ алгоритм. Поэтому о самоизоляции не может быть и речи. Наоборот, будет происходить последовательное улучшение языка.
число mod цикл2
Товарищ автор. Я категорически настаиваю, что ВЕСЬ код должен набираться в одной раскладке.
Ещё, рекомендую подумать, что Вы будете делать со знаками <>.
А зачем Хорошему Универсальному Языку Кодирования эти знаки? Так и писать: "больше" или "меньше".
На данный момент нет операторов < (меньше) и > (больше), и согласно текущей философии РЯП они не планируются, так как условие реализовано в виде кода:
если [переменная]
[следующая строка]
что значит:
если значение [переменная] больше или равно единице, то выполнить [следующая строка], иначе проигнорировать [следующая строка].
Долой неравенство! Все переменные — равны!
если значение [переменная] больше или равно единице, то выполнить [следующая строка]
А если равно 0.5? А почему?
А, главное, зачем так сделано? Почему не работать с логическими значениями?
Можно логические значения и не вводить. Как в BASIC — 0 / не 0. А логические операции в качестве True возвращают целое число, все биты которого подняты.
В принципе, если язык предназначен для расчётов, то я бы ввёл соглашение об именовании, чтобы по структуре имени можно было определить тип переменной. По первой букве, как в Фортране, или по суффиксу как в Бейсике. Правда, в отличие от Бейсика я бы сделал суффикс частью имени.
Зачем так сложно?
Что именно сложно?
Неявные логические операции — это сложно. Особенно когда у вас логическая операция возвращает снова число. С которым можно сделать арифметическую операцию зачем-то.
Искренне не понимаю, что в этом сложного. При таком соглашении логические операции становятся тождественными побитовым.
Другое дело, что для этого нужен целый тип данных. В бэйсике, например логические операции работали с Int16 (наименьший тогдашний тип). И True, соответственно было равно -1.
Искренне не понимаю, что в этом сложного
Зависит от того, кому вы преподаете. Объяснить начинающему, особенно ребенку, смысл фразы если 5, то
— сложно. Что значит "если пять"?
Ну, нам в школе объясняли так:
"Оператор IF выполняет действие после THEN в том случае, если выражение после IF не равно 0".
И закрепляли несколькими примерами.
Далее, рассказывали про операции сравнения, результатом которых может являться "True" или "False", причём False=0, а True=-1.
Такой нюанс, что -1 в дополнительном коде это шестнадцать единичек — на начальной стадии не нужно.
"Оператор IF выполняет действие после THEN в том случае, если выражение после IF не равно 0".
Понимаете, это объяснение магических слов. "Оператор IF". А я говорю о коде, который читается как текст: "если пять больше двух, то". В котором не надо запоминать магические слова.
А я говорю о коде, который читается как текст: "если пять больше двух, то". В котором не надо запоминать магические слова.
Чудес не бывает. Ключевые слова всё равно будут магическими, даже если они омонимичны со словами естественного языка.
А в чем тут чудеса-то? Если запись похожа на текст, ее можно читать. Никаких чудес.
Если запись похожа на текст, ее можно читать.
Вот только слова значат не совсем то, что в текстах на естественном языке. Вроде похоже, а вроде не совсем.
Вот только слова значат не совсем то, что в текстах на естественном языке.
Да нет, вполне то. "Если" значит "если".
Текст на естественном языке почти всегда многозначен, так что небольшие отличия легко скрадываются.
Текст на естественном языке почти всегда многозначен
А код — однозначен. И об этом нужно помнить.
небольшие отличия легко скрадываются
Это было бы верно, если бы для работы с языком не требовалось точно знать, какое из возможных значений слова "если" используется в языке.
В результате каждое слово получает пояснение, которое нужно помнить.
если бы для работы с языком не требовалось точно знать, какое из возможных значений слова "если" используется в языке.
Вы не поверите, но это ровно то, как мы работаем с естественным языком: понимая, какое конкретное из возможных значений сейчас используется. А когда не понятно — заглядывая в словарь.
Поверю. И, что характерно, мы это понимать учимся, причём небыстро. Код — это новый контекст, особенности которого тоже надо изучать.
… поэтому чем меньше когнитивный зазор, тем лучше для изучения.
Да, скорее всего Вы правы.
Очень интересен вопрос, может ли язык программирования быть подмножеством естественного языка. Мне мой личный опыт подсказывает, что скорее всего не может, но опыт одного человека — это не наука.
С другой стороны, из-за сходства языков программирования с английским языком — бывает трудно гуглить англоязычные материалы по языкам программирования. Гугл путает ключевые слова языка со словами в тексте. Я всё проклял, пока нашёл, что за беда у uglify с оператором with.
если значение [переменная] меньше или равно нулю, то проигнорировать [следующая строка], иначе выполнить [следующая строка].
Это еще хуже.
Это еще хуже.
Отнюдь. Это более-менее стандартное поведение для ряда языков программирования.
От того, что оно стандартное, оно лучше не становится.
Не трактовка <0 как true, а команда условного перехода не по произвольному логическому выражению значению, а по захардкоженному сравнению переменной с нулём.
В языке микрокалькуляторов (МК-61) были четыре разных команды условного перехода для x=0, x!=0, x>=0, x<0.
… и все это вместо того, чтобы сделать явное сравнение?
Ничего необычного. В вышеупомянутом языке микрокалькуляторов это именно так и работает. Регистр может инкрементироваться или декрементироваться при каждом обращении, а операторы условного перехода сравнивают его с нулём (писал выше, их четыре вида).
Я же не говорю, что это необычно. Я говорю, что это неудобно для языка общего назначения, и тем более — для языка для обучения.
(впрочем, если верить вашему описанию, то в языке для микрокалькуляторов как раз явное сравнение, просто оно является частью оператора перехода)
Новый язык должен быть с какой-то убийственной фичей, сладким синтаксисом или даже новой концепцией.
Делать что-то "такое себе" на Pascal не круто, даже для учебного пособия.
Как вариант возьмите Python и переведите конструкции на русский + плагин для подсветки кода. Дёшево и сердито, может получить распространение в школах на волне импортозамещения ;)
Кто-то никак не хочет отлипнуть от английского языка
ЛИнверт
Да, кто-то никак не хочет.
Вот код для вычисления простых чисел
Первый же вопрос к этому коду: начало
чего?
- ностальгируя
А ведь кто-то в школе начинал с Русского Алгоритмического Языка… (на самом деле, не я, т.к. по причинам, например, разным начал с бейсика).
ЗЫ. Стукни мне в башку что-нибудь подобное под высоким давлением, публикацию бы начал с минимальной уже реализованной грамматики, из которой код генерировался бы тем же flex-ом, а не со скомпилированной программы.
Хм. А почему тогда «остаток0 = число mod цикл2», а не «остаток0 = число остаток цикл2»? А также, почему «and (битовое И), xor (битовое исключающее ИЛИ), or (битовое ИЛИ)» — это всё ещё на английском?
Ну и дополнительный вопрос: с первых классов, думаю, учеников учат, что по-русски целая часть от дробной отделяется запятой. Будет ли русский язык программирования следовать русским нормам? Иначе, особо учитывая уже существующие or/xor/and/mod какая-то химера выходит.
3) Кто-то никак не хочет отлипнуть от английского языка.
Наверное, и шпрехает только на английском, используя слова типа стартап, коммит, заклозь, лайфхак, гамбургер, свитшот.
А как гамбургер будет на русском? «Жирный и богатый холестерином богомерзкий каравай»?
Так не бывает. Люди, которые занимаются разработкой — общаются текстом. А "кино" — это не документ.
promcod.com.ua/Article.asp?code=20190520195202043412
Русский Язык Программирования