Вече на п-п-р

Добавлено: **23.03.21 20:05**

БудДен писал(а): ↑
23.03.21 19:51
Я 1973 года.

Я 68-го. Очень приятно, что писали на одном и том же.

БудДен писал(а): ↑
23.03.21 19:51
Немного покритикую:

Ок.

БудДен писал(а): ↑
23.03.21 19:51
[*] динамическая типизация - это плохо, т.к. не позволяет сделать удобную среду разработки - из-за недостатка информации в тексте будет гораздо хуже работать автодополнение и переход к определению. Например, в C#, наверное, 90% кода со статической типизацией и 10%, где это нужно - с динамической. И плюс вывод типов, который позволяет меньше указывать типы напрямую. Пропорции можно насколько-то менять. Например, можно упростить контейнеры, если они будут хранить "любой объект" - тогда исчезнут все эти ковариантности и прочее. Примерно так сделано в лиспе - там встроенные контейнеры хранят любой объект. Но 0 статической и 100% динамической - это явно не золотая середина.

Даже не обсуждается.
Язык создается не для программистов, (даже типа, 1с-ники и ПХП-шники и Питонщики), а для простых людей. Простой человек имеет право не отличать unsigned int от double. Ему для нработы необходимо и достаточно понятия "число".

БудДен писал(а): ↑
23.03.21 19:51
"[*] чистый интерпретатор - это плохо, т.к. он медленный. Лучше всего - как в лиспе, когда можно смешивать интерпретируемый и компилируемый код, а также менять отдельные процедуры и типы, не прекращая выполнения программы. Естественно, это сложнее реализовать, чем интерпретатор, но оно того стоит. "

1С показывает вполне приемлемые результаты. А быстрее и не надо.
В примере с анимацией даже специально поставлена задержка:

Код: Выделить всё

	для кадрНомер=1 по списокКадров.количество() цикл
		для задержкаИндекс=1 по 1000 цикл
			задержкаИндекс=задержкаИндекс;
		конецЦикла;
		рядТекущий	= кадрНомер;
		текущееИзображение= списокКадров.значениеПолучить(кадрНомер);
		// memoryDisplayVARS();
		обновить();
		// сообщить(кадрНомер);
	конецЦикла;

БудДен писал(а): ↑
23.03.21 19:51
И просто дополнение - насколько я помню, блоки кода ничем не отличаются от замыканий, а замыкания сегодня есть во многих языках. Так что когда будете делать, посмотрите на тот же JS, чтобы сделать более понятно для публики.

Спасибо за совет. приму к сведению.

БудДен писал(а): ↑
23.03.21 19:51
В целом ок, ставим процесс на паузу, ждём, пока/если Вы дозреете до версии под ЯОС. ЯОС тоже пока будет зреть, там многого не хватает (например, https). А по презентации лучше всего сделать видеоролик и всё там показать.

Ещё рекомендую попасть в этот каталог: http://compiler.su/entuziasty-razrabotc ... roekty.php

Думаю, для этого достаточно оставить комментарий на сайте - список явно со временем растёт.

Спасбо! И про ЯОС тоже буду иметь в виду.

Добавлено: **23.03.21 20:10**

БудДен писал(а): ↑
23.03.21 19:51
чистый интерпретатор - это плохо, т.к. он медленный. Лучше всего - как в лиспе, когда можно смешивать интерпретируемый и компилируемый код, а также менять отдельные процедуры и типы, не прекращая выполнения программы. Естественно, это сложнее реализовать, чем интерпретатор, но оно того стоит.

Лучше делать байт-код, потому что почти также просто, как интерператор и скорость проседает совсем незначительно, а динамические возможности сохраняются.

Добавлено: **23.03.21 20:16**

MihalNik писал(а): ↑
23.03.21 20:10

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

100%
Именно так и плоанируется. Но пока не до этого. Это потом.

Добавлено: **23.03.21 21:26**

БудДен писал(а): ↑
23.03.21 19:51
И плюс вывод типов, который позволяет меньше указывать типы напрямую.

Я тут не понял что имеется в виду.

БудДен писал(а): ↑
23.03.21 19:51
Например, можно упростить контейнеры, если они будут хранить "любой объект" - тогда исчезнут все эти ковариантности и прочее.

У меня контейнер Класс ValueList (СписокЗначений) http://www.ritminform.ru/sanda/help/class_VALUELIST.htm и контейнер ValueTable (ТаблицаЗначений) http://www.ritminform.ru/sanda/help/cla ... ETABLE.htm хранят любые объекты. Не совсем понимаю какие с этим сложности.
Что имеете в виду?

Добавлено: **23.03.21 22:33**

Вывод типов - это когда в коде написано

Код: Выделить всё

б := 5

И компилятор сразу автоматически определяет, что б - это число. Насчёт unsigned int - это не отсутствие типов, а лишь степень их подробности или даже скорее то, подо что они заточены. Например, в том же лиспе (это мой любимый язык) есть тип "число", и можно сказать, что переменная имеет тип "число". Число делится на целое и плавающее, плавающее делится на одинарной и двойной точности, целое делится на ограниченное и неограниченное. Если в какой-то задаче нас не интересует, что конкретно за число, а просто нужно число, то мы так и пишем - "переменная б типа число", не детализируя. Это по той причине, что лисп создавался как язык для рассуждений. В Си и подобных языках типы нужны по той причине, что они в какой-то степени определяют необходимый объём памяти для хранения такого числа - ведь это языки для общения с железом. Хотя там это сделано довольно плохо. Всякие int64 - ещё ничего, а просто int - это какой-то ад, потому что в стандарте его размер чётко не определён.

Добавлено: **23.03.21 22:38**

ритминформ писал(а): ↑
23.03.21 21:26

БудДен писал(а): ↑
23.03.21 19:51
И плюс вывод типов, который позволяет меньше указывать типы напрямую.
Я тут не понял что имеется в виду.

БудДен писал(а): ↑
23.03.21 19:51
Например, можно упростить контейнеры, если они будут хранить "любой объект" - тогда исчезнут все эти ковариантности и прочее.
Что имеете в виду?

Не во всех языках такое есть. На мой взгляд, это скорее хорошо, но иногда можно запихнуть свиное рыло в калашный ряд, т.е. ошибиться - и тогда это плохо. Статическая типизация от этого защищает (в какой-то степени). Дальше, если в среде разработки мы пишем: "мойКонтейнер.ЗначениеПолучить(5)." и далее нажимаем Tab для автодополнения. То, если у нас нет статической типизации, то чем среда разработки заполнит список автодополнений? Либо всем, либо ничем. Если же известно, что мойКонтейнер хранит, скажем, веб-страницы, то в автодополнение сразу понятно, что может встретиться URL, исходныйТекст и т.п. В этом преимущества более подробной типизации. Недостаток - в том, что теряется непринуждённость работы с контейнерами. Например, если нужно скопировать данные из одного контейнера в другой, нужно следить за типами данных и в каком-то случае это может просто не получиться. Сложнее расширять программу и т.п. Т.е. есть у любого варианта и плюсы и минусы. Тем не менее, есть такая закономерность: для маленьких программ типизация скорее мешает, а для больших она скорее помогает.

Добавлено: **24.03.21 00:24**

БудДен писал(а): ↑
23.03.21 22:33
Вывод типов - это когда в коде написано
Код: Выделить всё
б := 5

Я не понимаю.
Это - операция присвоения.

БудДен писал(а): ↑
23.03.21 22:33
"И компилятор сразу автоматически определяет, что б - это число. "

И интерпретатор тоже самое делает.

БудДен писал(а): ↑
23.03.21 22:33
"Насчёт unsigned int - это не отсутствие типов, а лишь степень их подробности или даже скорее то, подо что они заточены."

Да. Но это определяет тип данных, которые хранит (представляет) переменная.

Как-то у нас проблемы в терминологии. Я никогда не слышал такой трактовки словосочетания "Вывод типов". Для меня это что-то новое.

БудДен писал(а): ↑
23.03.21 22:33
Например, в том же лиспе (это мой любимый язык) есть тип "число", и можно сказать, что переменная имеет тип "число". Число делится на целое и плавающее, плавающее делится на одинарной и двойной точности, целое делится на ограниченное и неограниченное. Если в какой-то задаче нас не интересует, что конкретно за число, а просто нужно число, то мы так и пишем - "переменная б типа число", не детализируя. Это по той причине, что лисп создавался как язык для рассуждений. В Си и подобных языках типы нужны по той причине, что они в какой-то степени определяют необходимый объём памяти для хранения такого числа - ведь это языки для общения с железом. Хотя там это сделано довольно плохо. Всякие int64 - ещё ничего, а просто int - это какой-то ад, потому что в стандарте его размер чётко не определён.

Я в курсе.

Добавлено: **24.03.21 00:31**

БудДен писал(а): ↑
23.03.21 22:38
но иногда можно запихнуть свиное рыло в калашный ряд, т.е. ошибиться - и тогда это плохо.

Ну, пможно и на 0 поделить. :)

"Статическая типизация от этого защищает (в какой-то степени). "

Я в курсе.

БудДен писал(а): ↑
23.03.21 22:38
Дальше, если в среде разработки мы пишем: "мойКонтейнер.ЗначениеПолучить(5)." и далее нажимаем Tab для автодополнения. То, если у нас нет статической типизации, то чем среда разработки заполнит список автодополнений? Либо всем, либо ничем. Если же известно, что мойКонтейнер хранит, скажем, веб-страницы, то в автодополнение сразу понятно, что может встретиться URL, исходныйТекст и т.п. В этом преимущества более подробной типизации.

Вы рассуждаете как программист. :) Пользователи (люди, которые пишут маленькие программы) этих проблем не испытывают.

БудДен писал(а): ↑
23.03.21 22:38
Недостаток - в том, что теряется непринуждённость работы с контейнерами. Например, если нужно скопировать данные из одного контейнера в другой, нужно следить за типами данных и в каком-то случае это может просто не получиться.

Я за более чем 20 лет пролграммируя на 1С77 ни разу не испытал таких проблем. :)

БудДен писал(а): ↑
23.03.21 22:38
Сложнее расширять программу и т.п.

Ну, я не сталкивался с такими сложностями. Хотя системы достаточно с большим количеством сущностей создавал.

БудДен писал(а): ↑
23.03.21 22:38
Т.е. есть у любого варианта и плюсы и минусы. Тем не менее, есть такая закономерность: для маленьких программ типизация скорее мешает, а для больших она скорее помогает.

Да. Я именно так и считаю.

Мне надо, чтобы писали бухгалтеры (как они писали в старой доброй досовской 1С) и менеджеры. А для этого надо делать наиболее просто.

Добавлено: **24.03.21 00:41**

В интерпретаторах числовые данные не должны для пользователя делиться на типы.
Точно так же, как и строковые. Не должен пользователь забивать себе голову диапазоном представляемых значений.
Мало того! Язык не должен ограничивать пользователя интерпретатора. Т.е. число -1234534534513451346234562345623.2346523456435634651346513434 должно восприниматься спокойно и не вызывать вопросов о способе его хранения в переменной.
У меня такое мнение.

Добавлено: **24.03.21 01:11**

Как-то у нас проблемы в терминологии. Я никогда не слышал такой трактовки словосочетания "Вывод типов". Для меня это что-то новое.

type inference = вывод типа, вот словарь: https://translate.academic.ru/type%20inference/en/ru/ Ну, может быть, "выведение типа" более однозначно.

Хотя системы достаточно с большим количеством сущностей создавал.

Если в 1С, то там всё же в основном сущностями наверняка были объекты базы данных (справочники, документы, регистры и что там ещё бывает), которые там в какой-то степени типизированы. Например, невозможно записать в какой-нибудь справочник запись от другого справочника, если у них различаются поля.

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

https://docs.google.com/spreadsheets/d/ ... =606456217

Все, кто делает что-то в ИТ, связанное с русским языком, по идее в нём должны быть заинтересованы, независимо от того, предпочитают ли они статическую или динамическую типизацию и т.п. Но формат таблиц гугл очень неудобен для администрирования. Думаю, в течение месяца-двух доделаю его и тогда будет анонс.

Добавлено: **24.03.21 02:07**

БудДен писал(а): ↑
24.03.21 01:11
type inference = вывод типа, вот словарь: https://translate.academic.ru/type%20inference/en/ru/ Ну, может быть, "выведение типа" более однозначно.

Блин!!! Определение типа результата! Определение типа значения-результата...

БудДен писал(а): ↑
24.03.21 01:11
Если в 1С, то там всё же в основном сущностями наверняка были объекты базы данных (справочники, документы, регистры и что там ещё бывает), которые там в какой-то степени типизированы. Например, невозможно записать в какой-нибудь справочник запись от другого справочника, если у них различаются поля.

Нет.
Я не 1С-ник, который чуть что - сравочник создает. :) После них конфигурации смотреть невозможно. Я нормальный.

Добавлено: **24.03.21 02:12**

БудДен писал(а): ↑
24.03.21 01:11
Но в общем я не хотел бы спорить, не думаю, что удастся Вас в чём-то переубедить, обычно из этого ничего не выходит - воззрения людей эволюционируют, но на это нужны годы, и причём они могут эволюционировать в разном направлении.

У нас, надеюсь, нет предмета спора. Я как человек от ассемблера (цифровой код, бейсик, фортран, паскаль ассемблер и только потом dbase-подобные языки) Вас прекрасно понимаю.

БудДен писал(а): ↑
24.03.21 01:11
Во всяком случае, если когда-то возникнет желание портировать Ваш язык и на ЯОС в том числе, то будет здорово. А пока следите за новостями - я постепенно пилю движок для вот такого словаря:

https://docs.google.com/spreadsheets/d/ ... =606456217

Все, кто делает что-то в ИТ, связанное с русским языком, по идее в нём должны быть заинтересованы, независимо от того, предпочитают ли они статическую или динамическую типизацию и т.п. Но формат таблиц гугл очень неудобен для администрирования. Думаю, в течение месяца-двух доделаю его и тогда будет анонс.

Да, да. Я понял. Вы тоже не забывайте про Санду. Через пару лет она будет пригодна для болььших проектов.

Например, мой учет и система закупок достаточно сложны. А в одном месте у меня крутится разработка ещё круче моего учета. Я планирую их переписать на Санда. Года через два-три.

Добавлено: **24.03.21 06:49**

Все, кто делает что-то в ИТ, связанное с русским языком, по идее в нём должны быть заинтересованы

Я заинтересован в толковом словаре. А в словаре переводов - нет. Потому что я не занимаюсь переводами.

Словарём занимается Апресян ("Активный словарь русского языка"), но что-то там тема застопорилась на 3-м томе (буквах "з" и "и")...

Добавлено: **24.03.21 10:35**

Значит, Лис не укладывается в мою идею и можно поправить мою формулировку. Это предоставляется читателю. Насчёт словаря Апресяна - может быть, его тоже надо подключить.

> Определение типа результата!

Ну я же этот термин не придумывал, а взял у кого-то. Во всяком случае, этот пример говорит о важности терминологии :) Но теоретически может быть, что выводится тип не только результата, но и операндов. Например, если мы определяем функцию, то компилятор какого-либо языка может выводить тип аргумента из операций, которые над ним делаются в теле функции. В этом случае "определение типа результата" не подойдёт, хотя не уверен, что в C# такое есть.

Насчёт неважности типа, хочу ещё предостеречь от грабель: "1"+1=11. Чтобы на них не попасть, операция конкатенации не должна обозначаться плюсиком. ЕМНИП в Бейсике сделали правильно, а вот в JS - нет.

Добавлено: **24.03.21 11:52**

ритминформ писал(а): ↑
24.03.21 00:31
Мне надо, чтобы писали бухгалтеры (как они писали в старой доброй досовской 1С) и менеджеры. А для этого надо делать наиболее просто.

История помнит много таких примеров. Бил-Гейтс каждая домохозяйка сможет писать на Бесике . В результате появились программисты.
Каждый пользователь сможет делать запросы на языке SQL. В результате имеем SQL-программист и NoSQL-программистов.
Каждый пользователь сможет создать свой сайт используя HTML. В результате отдельная профессия верстальщик, фронэндер, и JS-программист
JSON сложно упрощаем до человеческого YML, имеем DevOPS.

Вывод типов

Выведение типов, оно же вычисления типов. Сложный прием используемый в компиляторах для оптимизации программ.
Но в самом простом случае является обязательной стадией семантического анализа. Рода(Типы) переменных вы должны проставить над переменными и выражениями для вычисления результата. В 3-х оперенной форме для правильной расстановки нужно знать результат типа. И от него плясать.
Там ведь у вас не только у строк +. Но и у целых у дробных. У множеств.

И сцепку строк лучше делать не как в Бесике, а как в ПХП через точку.

Добавлено: **24.03.21 12:13**

Павиа писал(а): ↑
24.03.21 11:52
История помнит много таких примеров. Бил-Гейтс каждая домохозяйка сможет писать на Бесике . В результате появились программисты.

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

Павиа писал(а): ↑
24.03.21 11:52
Каждый пользователь сможет делать запросы на языке SQL. В результате имеем SQL-программист и NoSQL-программистов.

В РФ. В РФ программисты 1С и бухгалтерские работы выполняют. А вот товарищ рассказывал, что где-то за бугром менеджеры сами пишут SQL-запросы.

Павиа писал(а): ↑
24.03.21 11:52
Каждый пользователь сможет создать свой сайт используя HTML. В результате отдельная профессия верстальщик, фронэндер, и JS-программист

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

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

Добавлено: **24.03.21 12:18**

БудДен писал(а): ↑
24.03.21 10:35
Насчёт неважности типа, хочу ещё предостеречь от грабель: "1"+1=11.

Вот поэтому я категорически против приведения типов. В 1С, кажется, такое возможно, а у меня - нет. У меня такое запрещено.

БудДен писал(а): ↑
24.03.21 10:35
Чтобы на них не попасть, операция конкатенации не должна обозначаться плюсиком. ЕМНИП в Бейсике сделали правильно, а вот в JS - нет.

Не обязательно. Просто операция "+" не должна выполняться с парой "строка и число". Просто генерируется ошибка времени выполнения.

Добавлено: **25.03.21 12:38**

Обсуждение термина type inference отделено в форум по терминологии.

Добавлено: **25.03.21 22:28**

Я всё же осмелюсь продолжить критику: Вы сначала пишете, что Санда предназначен(а) для простых программ, но на горизонте в Ваших планах уже маячат сложные. Этот путь прошли уже многие языки, включая JavaScript и Python. Они начинались как языки для маленьких программ, потом перерастали себя и в конце концов на определённом этапе задумывались о добавлении статической типизации в той или иной форме. Однако если это не сделано сразу, то потом это уже делается гораздо труднее. Я столкнулся в лиспе ровно с той же ситуацией: без статической типизации ограничены возможности среды разработки. Т.е. я бы на Вашем месте постарался более чётко ответить себе на вопрос: для каких программ предназначен Ваш язык - для маленьких или для больших?

Далее, про "1"+1 - тут вопрос, отличается ли у Вас строка от числа вообще? Вы написали, что типы вообще не нужны. Но я бы посоветовал тогда изучить язык tcl. В нём есть только один тип - строка, и интерпретация этого типа зависит от контекста. Т.е., в определённых случаях строка может восприниматься как число, указатель, открытый файл и т.п. Это наиболее ужасно в плане грабель, однако работать на этом языке приятно. А почему? Я долго не мог понять, а потом понял: в Си объект в памяти будет представлен просто числом (адресом), если не постараться. В тикле же адрес имеет вид строки, и поэтому у всех объектов само собой получаются "говорящие имена". Обычно их образуют в подобие дерева, и они сразу "разложены по полочкам". Разбираться в такой среде и сохранять над ней контроль - гораздо проще. Я до сих пор не могу это осознать, настолько его философия отличается от других, хотя я на нём написал не меньше 100кб кода. Но исходя из того, что у Вас нельзя сложить строку и число, получается, что типы у Вас всё же есть. Но как тогда определить Вашу философию по отношению к типам?

Добавлено: **25.03.21 22:30**

Хотя я прочитал описание про типы - более-менее понял.

Добавлено: **26.03.21 07:19**

БудДен писал(а): ↑
25.03.21 22:28
Вы сначала пишете, что Санда предназначен(а) для простых программ, но на горизонте в Ваших планах уже маячат сложные.

Опять вопрос терминологии.
"Сложные" vs "большие".
Я прежде всего ориентируюсь на БД и учет. Там не бывает сложных программ.

БудДен писал(а): ↑
25.03.21 22:28
Я столкнулся в лиспе ровно с той же ситуацией: без статической типизации ограничены возможности среды разработки.

Прекрасно! Ещё раз говорю. Язык - для простых людей, а не для программистов. Их потребности, как правило, весьма ограничены.
В том же самом екселе 90 процентов юзеров кроме функции СУММ ничего больше не знают. Я уж не говорю о встроенном VB.

БудДен писал(а): ↑
25.03.21 22:28
Т.е. я бы на Вашем месте постарался более чётко ответить себе на вопрос: для каких программ предназначен Ваш язык - для маленьких или для больших?

Размер в данном случае не имеет значения как и количество строк в электроннойц таблице.

БудДен писал(а): ↑
25.03.21 22:28
Далее, про "1"+1 - тут вопрос, отличается ли у Вас строка от числа вообще?

Отличается.
http://www.ritminform.ru/sanda/help/lan ... aTypes.htm

БудДен писал(а): ↑
25.03.21 22:28
Вы написали, что типы вообще не нужны. Но я бы посоветовал тогда изучить язык tcl.

Беглое знакомство с Tcl/Tk прошло лет 10 назад. :)

БудДен писал(а): ↑
25.03.21 22:28
В нём есть только один тип - строка, и интерпретация этого типа зависит от контекста. Т.е., в определённых случаях строка может восприниматься как число, указатель, открытый файл и т.п. Это наиболее ужасно в плане грабель, однако работать на этом языке приятно. А почему? Я долго не мог понять, а потом понял: в Си объект в памяти будет представлен просто числом (адресом), если не постараться. В тикле же адрес имеет вид строки, и поэтому у всех объектов само собой получаются "говорящие имена". Обычно их образуют в подобие дерева, и они сразу "разложены по полочкам". Разбираться в такой среде и сохранять над ней контроль - гораздо проще. Я до сих пор не могу это осознать, настолько его философия отличается от других, хотя я на нём написал не меньше 100кб кода. Но исходя из того, что у Вас нельзя сложить строку и число, получается, что типы у Вас всё же есть. Но как тогда определить Вашу философию по отношению к типам?

Типы есть. Наверно, я изначально что-то не так разъяснил.

Добавлено: **20.05.21 19:54**

Вот приблизительно так.
Пока не думал о пределах. Пока где-то 16-32 знака после запятой и приблизительно 100 тысяч знаков до...

P.S.
Заливать новую версию пока не стал. Неделю-две потестирую ещё. Делал больше месяца так что пара недель ещё подождут...

Добавлено: **09.06.21 15:50**

Добавьте, пожалуйста, тег # р у с с к о я з ы ч н ы й я з ы к п р о г р а м м и р о в а н и я в первое сообщение (теги плохо работают, но всё равно без них ещё хуже).

Добавлено: **10.06.21 09:31**

БудДен писал(а): ↑
09.06.21 15:50
Добавьте, пожалуйста, тег #русскоязычныйязыкпрограммирования в первое сообщение (теги плохо работают, но всё равно без них ещё хуже).

Сделал

Добавлено: **10.06.21 11:27**

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

Добавлено: **11.06.21 12:17**

БудДен писал(а): ↑
09.06.21 15:50
# р у с с к о я з ы ч н ы й я з ы к п р о г р а м м и р о в а н и я

Не подумайте, что "придираюсь", но моя училка по русскому выпала бы в "осадок", глядя на столь часто употребляемые нами тавтологии:
"русскоязычный язык программирования" (уж лучше "русскоязычное программирование")

Добавлено: **13.06.21 22:13**

речь идёт именно о языках программирования, а не о русскоязычном программировании (которое может быть и на англоязычных с русскими идентификаторами). То, что слово "язык" применяется два раза, не кажется мне страшным, потому что тут есть человеческие языки и языки программирования. И те, и другие присутствуют в данном ключевом слове.

Вече на п-п-р

Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Длинная арифметика

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда

Re: Язык программирования Санда