Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Новости и прочее

Не поминайте всуе PL/1

Люди, которые не знают PL/1 и поминают его не к месту, очень раздражают нас — тех, кто знает PL/1.

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

Да, действительно раздражает. Вот, например, упоминание в типичной и далеко не новой статье на Хабре от 3 декабря 2012, «Ликбез по типизации в языках программирования».

Преобразования в неоднозначных ситуациях и преобразования с потерей данных — это очень, очень плохо. Ничего хуже этого в программировании нет. Если вы мне не верите, изучите язык PL/1 или даже просто поищите его спецификацию. В нем есть правила преобразования между ВСЕМИ типами данных! Это просто ад!

После слова «ВСЕМИ» еще не хватает трех восклицательных знаков, и тогда на этом накале пафоса уже можно было бы жарить картошку.

Автор статьи не знает, что в PL/1 есть переменные (т.е. данные) типа метка, типа файл, типа процедура, типа указатель, наконец, и всех их нельзя преобразовать. Ах, я придираюсь, оказывается, автор имел в виду только числа и строки? Тогда зачем писать про «между всеми» и про ад? Как говорится, во-первых, не из табакерки, а, во-вторых — не лысый чёрт! На мой взгляд, к аду гораздо ближе языки, где, например, символ «плюс» означает и арифметическое действие, и склейку строк. Вот там бывают веселые преобразования.

Но это старая статья, а вот в свежей статье от 25 ноября 2020 с названием «от Фортрана до Питона» Андрей Терехов пишет:

Американцы озлобились, когда в Европе появился Алгол-60, и сделали PL/1… Кошмарный язык! Сотни автоматических преобразований типов в другие типы. Как говорили, язык-оболочка. Несколько сот операторов: на любой чих отдельный оператор — кто их все запомнит? Тем не менее, этот язык стал довольно популярным и в СССР, поскольку появились ЕС ЭВМ. Я писал на нем, но тоже кошмарики случались. Опишешь в одной процедуре глобальную переменную А bin fix (целое), а в другой переменную А bin float (с плавающей точкой). Потом будешь долго искать ошибку — транслятор ничего не скажет

Вроде знающий и уважаемый человек. Пишет странное. Язык не поворачивается сказать, что пишет ерунду. Во-первых, PL/1 появился не по злобе на Алгол-60, а как его прямое продолжение. Да, именно он прямой потомок, а не Паскаль (выкидыш Алгола-68). Достаточно сравнить семантический разбор в трансляторах Алгола и PL/1 — ровно один и тот же набор основных структур: блочная структура, присваивание, условие, вызов, цикл, ввод-вывод. И никакой злобы.

Во-вторых, непонятно, что за «сотни операторов на любой чих» имеются в виду. Встроенные функции? Ну не пользуйтесь, изобретайте свои. Можно даже с точно такими же названиями, блочная структура языка это позволяет. По мне, так лучше использовать имеющиеся в языке (и в нормальной документации), как появившиеся в результате практической работы и придуманные опытными людьми. Да и ошибок с типами операндов будет меньше, ведь встроенные функции уже предусматривают операнды разных типов. Как их все запомнить? А тысячи разных функций из библиотек как запомнить? А здесь всего-то, несколько десятков (например, 84 штуки в PL/1-KT, включая всякие гиперболические тангенсы), а вовсе не сотен.

И, в-третьих, непонятно насчёт глобальных переменных. Глобальные переменные должны описываться в файле исходного текста один раз во внешнем блоке, на то они и глобальные, видны везде, повторять описание во всех процедурах не нужно. А если совсем в другом файле другая глобальная переменная вдруг с тем же именем оказалась — так сам себе злобный Буратино. В этом случае к компилятору-то (и к языку) какие претензии? Откуда он узнает, что этот другой файл — оказывается продолжение общего проекта и он (компилятор) когда-нибудь его тоже будет транслировать. Тогда уж претензии должны быть к редактору связей. И вообще-то есть специальные утилиты типа LINT для проверок глобальных переменных и типов операндов процедур из разных модулей.

Еще одно вздорное упоминание языка — это обвинение, что «любой текст (вариант: рассыпанная и случайно перетасованная колода перфокарт) считается программой на PL/1 и компилятор начнет его разбирать, хе-хе». Любой компилятор (кроме транслятора Дракона?) читает исходный текст посимвольно и, конечно, ему нужно прочитать несколько символов, прежде чем понять, что этот текст — не программа. В этом смысле PL/1 ничем не отличается и не выделяется из других: правильный текст должен строго начинаться или со слова BEGIN с точкой с запятой или с метки с двоеточием, за которым следует слово PROCEDURE, иначе это не PL-программа. Возможно, здесь ноги растут из неудачного решения разработчиков IBM-транслятора, когда на любую ошибку сразу выдается максимум информации о программе, включая таблицу встроенных функций. Это могло вызвать оторопь у новичка, когда на неправильно введенную колоду карт, он получал несколько листов распечатки ненужных ему данных.

Таким образом, большая часть упоминаний PL/1 обычно идет как негативный пример неудачного языка, при этом часто безосновательно его упоминают люди или вообще не имевшие с ним дела или имевшие, но очень давно, в другую компьютерную эпоху. Например, обсуждая обработку исключений, начинают вдруг вспоминать с какой версии Си/Си++ исключения появились в языках. Казалось бы, вот тут-то и упомянуть бы PL/1 как пионера в этой области, но нет. Справедливости ради, бывают, конечно, и упоминания в положительном ключе, когда вспоминают, например, удобный отладочный оператор PUT DATA или работу с битовыми строками, не требующую применять булеву алгебру к числам.

А что, разве у PL/1 нет недостатков и их нельзя вспоминать? Конечно, есть и можно, ведь язык появился более полувека назад, когда многие очевидные теперь вещи были совсем неочевидны, да и возможности взаимодействия с компьютером по сегодняшним меркам были чрезвычайно слабы. Тогда эта слабость заставляла тратить большие силы на ерунду вроде режима трансляции программы «до конца», даже при наличии ошибок или уже упомянутой выдачи программисту огромного объема данных при единичной простейшей ошибке.

Лично мне досадно, что с появлением персональных компьютеров, общее развитие программирования вдруг просело с уровня Алгола-PL/1 до уровня Си-Бейсика-Паскаля и ему потребовалось лет 10, чтобы опять достичь уровня, с которого можно было стартовать еще с начала 80-х. Напомню, что небывалая популярность IBM PC (появились в 1981 году, когда другие ПК уже были) во многом была связана с маркой, с престижем, с трендом: «у меня на столе стоит целый IBM!». Какой бы язык выбирали новички, если бы тогда имелась возможность богатого выбора? Ну, разумеется, тоже самый престижный: «язык языков», «язык профессионалов из ИБМ», т.е. тот самый PL/1. И ведь транслятор для ПК был уже почти готов. Но некрасивая история с участием Гарри Килдэла с одной стороны, и Билла Гейтса и IBM с другой, поставила крест на массовом внедрении PL/1 на персоналках. А поскольку число мэйнфреймов и их пользователей быстро сокращалось, язык потерял актуальность и постепенно (и несправедливо) превратился в пугало, обросшее мифами и анекдотами.

Могу привести анекдот, высмеивающий большое число ключевых слов в языке: «вчера разговаривал на улице с негром, используя словарный запас языка PL/1». Ну да, число ключевых слов в языке, пожалуй, побольше, чем в словаре людоедки-Эллочки. Да и то, не астрономическое число. В том же PL/1-KT в 128 штук помещаются все, включая экзотические составные операторы типа «не больше» (^>) и «не меньше» (^<). Это раза в 4 больше, чем слов в Паскале. Но при этом значительной частью этих слов можно никогда в программах не пользоваться и даже не знать об их существовании и поэтому называть так свои переменные (как в каламбуре IF THEN=ELSE THEN ELSE=IF;)

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

И, напоследок, о том, что даже упоминание всуе может иногда принести пользу, т.е. возвращаясь к примеру А. Терехова с глобальными переменными. Я проверил, действительно такой ляпсус был и в компиляторе PL/1-KT. Это связано с блочной структурой. При разборе описаний каждое имя проверяется на уже такое же, встретившееся в данном блоке. Тогда это ошибка типа «уже было». Но в других блоках точно такое же имя может быть у другого объекта — в этом и состоит «блочная» видимость. Вот при таких проверках и забыли про проверку на атрибут глобальности «EXTERNAL», который как раз «ломает» блочность. Такая проверка вводится легко, но я решил кроме этого еще обобщить поиск сомнительных мест: если в объемлющем блоке есть точно такое же имя с атрибутом «EXTERNAL», то сразу выдавать предупреждение, даже еще не разбирая атрибуты текущего имени. Формально ошибок здесь нет, но если это точно такой же объект, то его описание можно просто убрать — ведь этот же объект уже виден «сверху». А если это другой объект и без атрибута «EXTERNAL», то странно, что уже есть точно такое же, да еще глобальное имя. Лучше обратить внимание программиста на потенциальную опасность ошибки.

При этом многие компиляторы неудовлетворительно работают с предупреждениями, т.е. сообщениями, которые не меняют генерацию кода. Обычно можно только их отключить, так как при большом количестве, на них перестают обращать внимание. В PL/1-KT применен другой подход. С каждым предупреждением можно разобраться отдельно, и, если, в данном случае так и было задумано (ошибки нет), можно, так сказать, закомментировать данный фрагмент исходного текста от выдачи предупреждений с помощью указания прямо в тексте специального ключа. Тогда при изменении текста программ выдаются только новые предупреждения

А при очередном упоминании PL/1 у меня часто возникают ассоциации с упоминанием СССР в современных (да и в старых) буржуазных СМИ: обязательно с негативным оттенком, реальный или вымышленный недостаток преувеличен до искажения. И большинство людей возразить не может, поскольку о предмете личного мнения и опыта не имеет.



Автор: Д.Ю.Караваев. 12.12.2020

Опубликовано: 2020.12.12, последняя правка: 2020.12.12    15:24

ОценитеОценки посетителей
   ████████████████████████ 8 (57.1%)
   ███ 1 (7.14%)
   ███ 1 (7.14%)
   ████████████ 4 (28.5%)

Отзывы

     2020/12/12 16:02, Автор сайта          # 

Когда появился PL/1? Всего лишь 20 лет после ENIAC! Это сейчас легко критиковать PL/1. А вот попробовали бы критиковать его в то время. С чем тогда его можно было сравнивать? С Фортраном, Коболом, Лиспом, APL. Алголом. Вот, пожалуй, и всё. Тогда не только языков, но и программистов было в тысячи раз меньше. В тысячи (если не в миллионы!) раз меньше было опыта и научной базы. Не даром говорят: «Не критикуйте родителей. Они выросли без Гугла и Википедии».

Да, некоторые вещи в PL/1 архаичны. Однако нельзя сказать, что «он первый начал». Если хотим критиковать «goto», то надо вспоминать Фортран, а не PL/1, потому что Фортран первый ввёл в практику «goto». Не нравится многословные операторы? Претензии надо адресовать в первую очередь к Коболу. И тогда на долю PL/1 остаётся не так уж и много критики.

     2020/12/18 16:04, Автор сайта          # 

Вспомнил некоторые не очень известные факты о PL/1:
  • PL/1 был первым языком, использующим /* */ для комментариев.
  • PL/1 был первым языком, который использовал нотацию -> для указателей.
  • PL/1 был первым языком, который использовал термин «статический» для хранения переменных, не связанных со стеком.
  • PL/1 был первым языком высокого уровня, используемым для написания операционной системы (Multics).
  • PL/1 был первым языком, который обрабатывал исключения на основе стековых фреймов (называемых «условиями», т.е. condition).
Так что мы в чём-то обязаны этому языку. Надо не забывать о его вкладе в жизнь программистов.

     2021/02/17 09:01, jobless          # 

В середине 80-х прошлого века меня били (фигурально) в курилке за моё задание (JCL — Job Control Language — язык управления заданиями). Я курил, оно (задание) работало, а «PRIMUS» у всех висел. А всё потому, что я набрался наглости и конвертировал исходную ленту в результирующую, используя многозадачность и асинхронный ввод/вывод на PL/1. И ещё волшебство конвертации, использующее базированные структуры, наложенные на буферы ввода — вывода и структура = структура BY NAME. С тех пор всевозможные статьи на тему асинхронности и многозадачности, выдаваемые за супер-прогресс в программировании, воспринимаю в лучшем случае с улыбкой.

     2021/02/17 11:00, Бурановский дедушка          # 

Ну если «PRIMUS» висел, значит многозадачность работала не очень хорошо. Многозадачность в ЕС ЭВМ работала без тормозов, если все задания работали с вводом/выводом. Но если запускали расчётную задачу, то начинало тормозить.

Люди, вкусившие плоды многозадачности, испытывали разочарование от однозадачности DOS. «Как посадить за персоналку ещё одного человека, который бы никому не мешал, а просто вводил текст? Ах, никак...».

     2021/02/18 10:35, jobless          # 

Что значит хорошо работала ... Вы же не переспросили по поводу MFT, MVT, SVS и вероятно не обратили внимание на асинхронный ввод-вывод. Части алгоритма, занимающиеся трансформацией одной структуры в другую, не ждали ввода-вывода и создавались как подзадачи на каждый поставленный в очередь буфер, ну это если не было уже освободившейся ранее созданной подзадачи. Если ещё и знаешь, как повысить приоритет своего задания в MVT, то отобрать с такой организацией работы все ресурсы очень легко. Для коллективной работы в разгар рабочего времени это была настоящая наглость. На вход подавалась лента с телеметрией от http://militaryrussia.ru/blog/topic-604.html

Благодаря PL-скому BY NAME отпала необходимость переписывания под каждые испытания насмерть "запатченой" и, как следствие, запутанной программы на ассемблере. И естественно ещё и благодаря битовым полям в базированных структурах. http://www.iron-spring.com/prog_guide.html#mt В переводных учебниках этот раздел в 99% случаев отсутствовал. Думаю и авторы многих учебников, знающие PL/1 по другим таким же учебникам не подозревали о этих возможностях.

     2021/02/18 20:39, kt          # 

Не понял, о какой возможности речь? Она не указана в справочнике Фролова и Олюнина?

     2021/02/18 21:20, jobless          # 

Прям неожиданно, под занавес стр. 269 — 272 и это только в скользь о вводе-выводе. Но согласитесь, что в подавляющем числе учебников о многозадачности, асинхронности, событиям и т.д. и т.п. даже и не упоминалось. Именно по этому через много лет с улыбкой воспринимаю эти термины подаваемые в ореоле новизны. Нашёл, стр. 105. Оператор вызова процедуры имеет вид (при отсутствии многозадачности)
CALL pa
где p — имя и т.д. Единственный намёк на то, что многозадачность таки может присутствовать.

     2021/02/19 08:50, jobless          # 

И кстати по поводу EXTERNAL. Как то мне показалось, что многие теряют главный смысл.
Вот одна из самых значительных для меня книг с упоминанием PL/1 http://museum.lissi-crypto.ru/exhibits/23/ Держал в руках и гражданское издание, но запомнилось именно это.

     2021/02/19 09:02, kt          # 

Даже не знаю. Всегда считал основной справочной литературой «Практический курс программирования на языке PL-1» Первое издание 1983. У меня второе, 1986 года тиражом 111 000 экз. (т.е. общий тираж более 200 000) Из-во «Наука» ИБ №12824. Например, там есть глава 12 «Параллельное выполнение фрагментов программы». 12.1 «Асинхронные операции ввода и вывода». 12.2 «Мультизадачность». С самого первого дня знакомства с языком подразумевалось параллельное выполнение, как встроенная возможность.

     2021/02/19 09:21, jobless          # 

Да вы правы, помню эту книгу. Возможно я преувеличиваю. Но вспомнил я всё это недавно читая на опеннете новость про Rust 1.37:

Дополнительно можно отметить начало тестирования проекта Async-std, предлагающего асинхронный вариант стандартной библиотеки Rust (порт библиотеки std, в котором все интерфейсы предложены в версии с async и готовы для использования с синтаксисом async/await).

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

     2021/02/19 09:46, kt          # 

На этом сайте уже было обсуждение, что многие программисты текущего поколения, считают программистов предыдущего поколения чем-то вроде дикарей с луками и стрелами. Забывая, что и до "игрушечного" ПО IBM-PC/XT было вполне себе развитое и обжитое ПО.

Вот поэтому я и жалею, что хотя бы урезанный PL/1 массово не появился на ПК в 1981 году. Тогда бы мы ушли гораздо дальше на текущий день и не пришлось бы заново с нуля "открывать" исключения, параллельность и т.п.

     2021/02/19 11:49, jobless          # 

Предполагаю, что кто-то из причастных к pl1.su в диалоге. Не нахожу информации о том кому (юр/физ лицо) принадлежат права и под какой лицензией распространяется. Я о PL/1-KT естественно.

     2021/02/19 14:29, kt          # 

Авторские права на PL/1-KT, очевидно, принадлежат Д.Ю. Караваеву. А лицензия (кстати, а где это должно быть написано?) что-то близкое к Free GPL

     2021/02/19 15:23, jobless          # 

Для тех, кто в теме, очевидно. Для любого, кто например, через поиск попал на pl1.su, абсолютно не очевидно. И по всей вероятности https://ru.wikipedia.org/wiki/Бесплатное_программное_обеспечение . Ибо если GPL, то совсем не обязательно, что бесплатно, но вот что обязательно — это указанный канал получения исходников.

http://www.iron-spring.com/faq.html — тут, например, всё предельно просто всё написано про открытые и закрытые части, сопутствующие лицензии и права тех, кто рискнёт что-то своё выпускать, используя этот компилятор. Хотя тоже пришлось поискать.

     2021/02/19 16:21, kt          # 

А по-моему, в РФ все эти ГНУтости и прочие лицензии юридически ничтожны. Нет у нас таких терминов и понятий. Это для американских судов годится, а у нас должен быть заключен договор, если речь о деньгах. Авторское право — да, есть понятие и его можно доказывать в нашем суде. а все остальное (не оформленное договором) — детские игры.

     2021/02/21 17:07, jobless          # 

Я как бы не в тему, но всё же, регистрация на pl1.su работает? "АККАУНТ В ОЖИДАНИИ ПРОВЕРКИ: Ваш аккаунт ещё не активен. До того, как Вы сможете войти, администратор должен активировать аккаунт". О чём это и как долго ждать?

     2021/03/13 03:02, Comdiv          # 

А по-моему, в РФ все эти ГНУтости и прочие лицензии юридически ничтожны.

Дмитрий Юрьевич, от неприятностей в суде Вас спасёт не "а по-моему", а то, что, к счастью, вряд ли такой суд когда-либо состоится. Свободные лицензии не ничтожны в РФ, а вполне рабочие. Лицензию можно выводить в справке и где-нибудь на сайте, где транслятор распространяется. Если о лицензии ничего не сказано, то по умолчанию считается, что ничего нельзя и потенциальных пользователей от суда спасает лишь то, что Вы, очевидно, тоже не стали бы ни с кем судиться.

     2021/04/06 13:25, kt          # 

Как-то не обращал внимание на число ключевых слов в текущей версии С++, вот случайно увидел табличку:
http://rsdn.org/forum/philosophy/7983503.flat

Однако... в С++, оказывается, было 75 ключевых слов, а во всяких С++11 и С++20 добавлено ещё 42. Итого 117 штук.

В PL/1-KT 128 штук (хотя в "полном" PL/I больше), считая и составные операторы, всякие >= <= ^= ^> То есть почти то же самое, но PL/1 — "монстр, все запомнить было невозможно", а это другое, "естественный процесс развития" ))

     2021/04/07 15:34, Автор сайта          # 

Видимо, лягушку варили постепенно. Она и не заметила, как температура выросла с 75 до 117.

     2021/04/07 20:27, Клихальт          # 

Думается, что в повседневной практике и в PL/1 и в С++ используется гораздо более аскетичное подмножество, нежели полный стандарт языка.

     2021/04/17 18:29, Comdiv          # 

(С++)То есть почти то же самое, но PL/1 — "монстр, все запомнить было невозможно", а это другое, "естественный процесс развития"

О том, что С++ — монстр, говорили и за 20 лет до C++20. И дело, конечно, не в ключевых словах, так что предположу, что в объёмности С++ давно превзошёл PL/1, что никак не отменяет критику последнего.

     2021/06/14 15:36, kt          # 

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

В Rust 2021 вводятся зарезервированные незарезервированные слова, поскольку с помощью префикса "K" можно писать конструкции типа:

k#keyword, позволяющее писать ключевые слова, которых ещё нет в текущей редакции. Например, хотя async и не является ключевым словом в версии 2015, этот префикс позволил бы нам принять k#async в редакции 2015, не дожидаясь выхода редакции 2018, чтобы зарезервировать async в качестве ключевого слова.

     2021/06/16 13:10, Александр Коновалов aka Маздайщик          # 

Напомнило, что в C# можно создавать идентификаторы, совпадающие с ключевыми словами, если в начале имени написать знак @, например, @if, @while. Смысл в том, что C# язык для платформы .NET, которая изначально многоязыковая. А значит, библиотеки для неё могут писаться не только на C#, но и на других языках с другими ключевыми словами. Можно написать библиотеку на Visual Basic, где do не является ключевым словом, и назвать таким образом функцию. При использовании библиотеки из C# придётся написать @do.

     2021/11/07 09:05, kt          # 

Попалась на глаза статья на Хабре https://habr.com/ru/post/587428/ "Язык программирования C∀ (CForAll)", где в качестве новых возможностей, среди всего прочего, упоминается возможность встраивания одной структуры в другую с помощью ключевого слова inline. Автор статьи удивляется, почему сразу так не сделали в СИ? Но когда я в комментарии напомнил про "like" в PL/1, появившуюся ещё 55 лет назад — заминусовали....

     2021/11/08 17:03, Автор сайта          # 

Я поборолся с этой несправедливостью, поставил плюс :) А язык, конечно, интересный. Не без огрехов, но за многие вещи — просто 5 баллов.

     2021/11/08 19:06, kt          # 

Ну, так общее развитие ИТ идет. И разработчики средств становятся мудрее с каждой неудачей )) Чувствуется, что здесь не умозрительно добавлялись возможности, а на основе большого практического опыта. Но все-таки с возведением в степень — погорячились. В комментариях справедливо указали, что иногда сходу трудно сообразить в какую сторону повернута косая.
В этом отношении мне нравится старый синтаксис: все четыре возможные комбинации * и / что-нибудь, да означают. Т.е. полное использование )

     2021/12/17 07:57, Михаил          # 

Может кто-то вспомнит. Ходила такая шутка в 80-х. Очень простая задача и несколько вариантов запрограммиравать на PL/1. Уже не помню был ли текст переведен, что касается оценки кода. Общее название, что-то вроде "What kind of programmer you are". В зависимости от кода (одна или несколько строк) — "старую собаку не заставишь лаять по-новому — Фортран программист", математик, разработчик компиляторов, выпускник школы IBM и т.д.

     2021/12/17 18:51, Автор сайта          # 

Тест. Какой Вы программист? Именно эта страница является русским переводом шуточных тестов, которые вспомнились Вам.

     2021/12/18 03:57, Михаил          # 

Да, именно этот.

     2021/12/20 11:40, kt          # 

Наконец-то попалось адекватная (на мой взгляд) храктеристика PL/1. В сети есть множество сайтов, имеющих страничку «История языков программирования», где каждому языку дается краткая характеристика.

Обычно первым идет Фортран, затем Алгол, затем или Лисп или Бейсик. И там же PL/1, описание которого всегда оканчивается фразой типа «язык получился сложный» или «неудача проекта обусловлена сложностью языка». И вот натыкаюсь на такое описание, где тоже есть фраза о сложности, но затем следует разъяснение: «… сложностью языка, точнее его громоздкостью, поскольку сложных концепций язык, вообще говоря, не имеет…». Вот оно! Если, к примеру, есть карманный словарик иностранного языка и огромный толковый словарь, можно ли сказать, что первый — простой, а второй — сложный? Скорее, первый — маленький, а второй — большой. «Большой» — не равно «сложный». Сколько раз встречаю фразу: «на языке Си это решается с помощью библиотек». Ну да, решается. Например, в 16 наиболее используемых библиотеках Windows имеется 9100 подпрограмм API. Изучить их все нереально и совершенно не нужно. И язык, на котором написаны программы, использующие API, сложнее от этого не становится.

Почему же в сознании многих PL/1 остался как «сложный», а не просто «большой». По-моему это чисто психология. Увидев большой (по меркам 80-х) список встроенных функций, человек огорчается: я обязательно должен изучить их все! Они же входят в язык! А я должен обязательно знать язык целиком! А, например, ввод-вывод формально в Си не входит. Описание Си маленькое. Но попробуйте начать программировать на нем не изучив подпрограмму printf. Поэтому, считаю, нельзя говорить, что printf не входит в язык. Входит. И без разницы, в системной ли она библиотеке или нет. И сказки про «сложный» PL/1 пора перестать вдалбливать в сознание очередного поколения программистов. Обычный большой язык. Не сложнее остальных больших.

     2021/12/21 00:13, Автор сайта          # 

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

В 60—70-е годы PL/1 был сложнее, чем Фортран, Кобол, Алгол и Бейсик (а других языков тогда и не было). Это вполне объективная и правдивая оценка, справедливая именно тогда. В тот момент времени он действительно был сложный — относительно тех языков. Но сейчас, объективно говоря, есть масса языков, которые куда сложнее PL/1. Но откуда сегодняшние программисты черпают сведения о PL/1? Они опираются на мнение 50-летней давности! А оно гласит, что PL/1 сложный! А собственного мнения они не имеют, поскольку этот язык они не изучали и изучать не собираются. Вот поэтому Ваше вполне объективное мнение просто утопает в общем хоре не совсем сведущих людей.

P.S. Думаю, что на сайте progopedia.ru (энциклопедия языков программирования) можно поподробнее написать об этом языке. И не забыть сообщить о наличии бесплатного отечественного компилятора под платформу Wintel :)

     2021/12/25 10:30, kt          # 

Зашел на progopedia.ru и попробовал оставить заявку. Как-то сомневаюсь, что эти заявки сейчас кто-то рассматривает. По части PL/1 там есть только одна битая ссылка на RainCode. Согласен, что если древние оценки (не только языков программирования) не пересматриваются, то возникают ошибочные суждения и мифы. Чаще всего — негативные.

А в статье из Википедии очень странно описаны недостатки:

Вместе с тем, PL/I имеет и ряд недостатков, затрудняющих изучение и использование языка. Основные из них таковы. Во-первых, имеется много дублирующих друг друга средств, их сложно запомнить, не ясно, что когда применять, кроме того, это снижает как скорость трансляции, так и скорость выполнения программ. Во-вторых, программы получаются не совсем машинно-независимыми.

Безотносительно к конкретному языку.Как дублирование может влиять на скорость трансляции? Или на скорость выполнения?

Упоминание скорости трансляции выдает древний текст недостатков. Кого сейчас волнует скорость трансляции?. Это 45 лет назад Вирт её упоминал и оценивал нормальную скорость как страница в секунду. Что такое страница — он не объяснил. В моей реализации скорость трансляции примерно 500 байт в секунду на каждый мегагерц тактовой частоты. Т.е. за ту же секунду транслируется программа с исходным текстом в полмегабайта.

     2021/12/25 13:33, Автор сайта          # 

Думаю, что стоит собрать коллекцию мифов и предрассудков, связанных с PL/1, систематизировать их и написать статью-опровержение на сайте pl1.su под названием «Опровержение мифов о PL/1». А затем внести правки во все электронные энциклопедии, сделав ссылку на авторитетный (в терминах Википедии) источник — собственную статью.

progopedia.ru ... сомневаюсь, что ... заявки сейчас кто-то рассматривает.

Если не ошибаюсь, основательница этой энциклопедии — киевлянка, написавшая на Хабре статью «Моя бабушка — программист». Может, ей теперь не до того, слишком занята. Или охладела к собственному начинанию. А может теперь переписывает своё детище на мове в зоне ua.

     2021/12/25 14:55, Gudleifr          # 

Проблема PL/1 только одна — это язык программирования на все случаи. Такой же оксюморон, как "профессиональный программист". Всяк, умеющий инженерить, да научиться программировать на том, что есть. И всяк, владеющий началами системного программирования, создаст себе для этого удобный язык. Вопрос не в том, что существующие программно-аппаратные системы чего-то не умеют, вопрос в том, что они сделаны за деньги и ради денег. И для получения "чего-то кроме денег" нужен злобный хакер, а не ещё одна "среда воистину правильного и толерантного языка".

     2021/12/25 17:16, kt          # 

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

Почему-то предполагается, что сначала человек изучит язык целиком, и только потом начнет его использовать. Ничего подобного на практике (и из личного опыта) не наблюдается. Чтобы использовать несколько инструментов не обязательно досконально знать все. Разумеется, в этом случае и программы сначала неэффективные и сообщения об ошибках непонятные. Но этот этап быстро проходит и язык перестает казаться сложным. В случае же PL/1, вина лежит полностью на IBM, которая не придала значения начале новой эры (которую сама же и открыла) — эры персональных компьютеров. Продавался бы с самого начала IBM-PC/XT с MS-DOS и PL/I-86 — ни у кого и мысли бы не возникло, какой язык использовать.

     2021/12/25 17:56, Автор сайта          # 

Проблема PL/1 только одна — о нём все забыли, а IBM вовремя не напомнила. Естественные языки — они тоже на все случаи жизни. Но их учат по частям, а не сразу целиком.

Языки Си и Паскаль ненамного моложе. И то, что они «бесхозные», без фирмы-толкача, в отличие от PL/1, их не убило. Значит, у них крепкая генетика, которая позволила выжить среди сорняков. Но при перекрёстном опылении гены PL/1 попали во многие языки.

     2021/12/25 19:00, kt          # 

На мой взгляд, главным "злодеем" здесь выступила мамочка Б.Гейтса. Будучи членом одного из советов директоров IBM, она нашептала всем не связываться ни с кем, кроме её любимого сыночка)) Правда, речь ни шла ни о каком PL/1, а вопрос был в операционной системе для IBM-PC. Но так получилось, что специалист, создавший CP/M, создал и транслятор с PL/1. А поскольку с операционкой IBM его элементарно кинула (практически ограбила), то и ни о каком трансляторе в составе IBM-PC речь ни пошла. Транслятор так просто не украдешь, как маленькую CP/M, а других трансляторов тогда ещё не было.

Почему мамочка? Думаю, руководству IBM совсем не требовалось никого кидать. Оно бы просто наняло себе любого специалиста и дело в шляпе. А так получилось, что единственный готовый транслятор с PL/1 для компьютера IBM оказался под запретом в самой IBM. Но свято место пусто не бывает — и это место заняли Си и Бейсик, а чуть позднее — Паскаль.

     2021/12/25 19:47, Автор сайта          # 

готовый транслятор с PL/1 для компьютера IBM оказался под запретом в самой IBM.

Следовало бы уточнить, что не компьютер IBM, коих было множество, а IBM PC, фантастический взлёт которого в самой IBM не предвидели. Соответственно там не стоили долгосрочных планов — ни насчёт ОС, ни насчёт языков и компиляторов. Им надо было просто заткнуть дырку в возникшем спросе. Но спрос после выпуска IBM PC не собирался оставаться на месте, а ошеломительно вырос. То, что на IBM PC появился компилятор Си, у которого не было «хозяина», ещё раз говорит об отсутствии каких-то стратегий на тот момент. Так сложилось стихийно.

Тем более PL/I-86 не был совместимым с обычным PL/1 для остальной техники IBM. Компилятор VisualAge PL/I у IBM появился под OS/2 в 1996 году, а под Windows NT — в 1999 г. Это, по-моему, опять говорит о том, что фирама IBM оказалась неповоротливым монстром, она не держала нос по ветру.

Но что теперь об этом говорить? Теперь это всё в истории. К чему на неё оглядываться? Если б история пошла по другому пути, автор первого компилятора не бросил бы его и развивал. А Вам не довелось бы «подхватить упавшее знамя» PL/I-86 и довести компилятор до нынешнего уровня.

     2021/12/25 21:21, kt          # 

В 90-е наше предприятие выписывало PC Week. И я его регулярно листал. После смерти Килдэла в 1994 был огромный всплеск публикаций о нем. Сначала я даже не сопоставлял его с автором транслятора, когда дошло, начал искать ответ, почему о его трансляторе ничего не пишут.

Казалось бы, вот Петер Нортон его хвалит ещё в PC Magazine от 15 мая 1984. Бери да пользуйся. Но нет. Полунамек был в документации по MS-DOS. Типа: мы бесплатно даем MS DOS, но Вы можете отказаться от неё и за $1000 купить и поставить CP/M-86. Для миллионов новых пользователей какая-то там ОС — это была китайская грамота. А тут плати большие деньги за что? За то же самое, что MS-DOS? Зачем Килдэл назначил такую конскую цену? А ведь Килдэл такой цены не назначал. Это сделала сама IBM. Возможно и с транслятором что-то похожее было: «формально верно, а по существу издевательство».

Лет 15 назад в сети мелькнула статья с подчеркнуто жёлтым названием «Кто же убил Гарри Килдэла?». Автор толсто намекал, что Микрософт — это всего лишь инструмент борьбы IBM с Антимонопольным комитетом и капиталы Микрософт и IBM надо не сравнивать, а складывать.

Вот такая извилистая история, которая, да, повлияла и на 35 лет моей жизни…

     2021/12/25 21:34, Автор сайта          # 

Как говорит избитая фраза, «история не знает сослагательного наклонения». С другой стороны, был бы жив и здоров Килдэл — сложилась бы так интересно Ваша судьба?

     2021/12/25 22:04, kt          # 

"Я думаю, было бы то же самое. Дело не в дороге, которую мы выбираем, а в том, что внутри нас заставляет выбирать дорогу"

     2021/12/25 22:23, Gudleifr          # 

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

В том-то и дело. Имея на руках BASIC, Debug и справочник Журдена, PC-пользователь мог запрограммировать почти все, что нужно. Но мощный инструмент, вроде PL/I или Турбо-Паскаля мог только создать такую иллюзию внутри искусственно созданного "аквариума". Ведь, доступ к системе и машине, они имели только посредством использования костылей.

Ведь в случае единственного инструмента «если у вас в руке молоток — все вокруг кажется гвоздями».

И большинство полезных программ, которые мы знаем, именно так и были написаны.

     2021/12/25 22:31, Автор сайта          # 

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

Я не ставлю под сомнение то, что было внутри Вас. Просто Вашу работу над компилятором запустила цепочка случайных событий: к вам на работу поступил PC под MS DOS 3.0, на котором был единственный компилятор, но он был под DOS 1.0, что приводило к проблемам. И Вы взялись его дорабатывать. Но если бы:
  • компилятор шагал в ногу со временем, то его не пришлось бы дорабатывать;
  • там был компилятор, допустим, Модула-2, то Вы учили бы именно этот язык.
Тогда у истории возникают точки бифуркации.

     2021/12/26 15:14, kt          # 

Все-таки не хотелось бы, чтобы у кого-то сложилось впечатление, что наемный убийца из IBM устранил Килдэла и поэтому PL/1 для IBM PC исчез как конкурент, пока его не возродили в СССР. Digital Research выпустила транслятор в 1984 и до конца года выпустила ещё два релиза, а потом все кончилось и за 10 лет (до гибели Килдэла) ничего по этой части не было выпущено.

А заниматься транслятором все равно пришлось бы из-за руссификации. Оригинальный транслятор не позволял писать по-русски даже комментарии, все символы больше 128 воспринимались как управляющие. И совершенно невероятно, чтобы в 1984-5гг. на PC появилось бы что-то отличное от Фортрана или ПЛ/1 (два продукта DR) вроде Модулы, поскольку DR была тогда лидером по микропроцессорам, остальные просто не успевали создать трансляторы, кроме примитивных типа Форта.

А времени у нас совершенно не было. Мы сразу начинали на PC с больших задач и Бейсик бы здесь не помог. Поэтому многое было заранее предопределено объективным ходом вещей.

     2021/12/26 16:50, Автор сайта          # 

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

Русификацию можно было провести «снаружи», не влезая внутрь компилятора — подобно тому, как мне довелось русифицировать Си. Програмуля даже до тысячи строк не дотягивает. Дёшево и сердито.

И совершенно невероятно, чтобы в 1984-5гг. на PC появилось бы что-то отличное от Фортрана или ПЛ/1…, вроде Модулы

Если на PC, который попал в вам, был единственный компилятор, то это не говорит, что других не существовало в природе. Просто в СССР не любили тратить деньги на ПО. Тот же Turbo Pascal появился уже 1983 году! Он мог попасть на ваш PC! Наверняка уже были компиляторы C. Просто лезть за фактами в сеть не очень охота.

     2021/12/26 17:45, kt          # 

Возможно, я невнятно выразился. Не вообще невероятен Паскаль на PC в 1985 году, а невероятен на нашем предприятии. У нас вообще-то персональные компьютеры были довольно распространены и охотно использовались с начала 70-х. Я имею в виду удачную и работоспособную машину «Мир-2». Поэтому к появлению IBM PC отнеслись серьезно (и денег они тогда стоили больших). Мой первый PC вовсе не был персональным потому, что был организован класс из 6 компьютеров и организовано подразделение из двух сотрудников по уходу за ними. Пользователям выделялось 4-5 часов каждому в день.

Так вот, невероятность Паскаля заключается в том, что предприятием было приобретено и ПО к IBM PC. Но у нас тогда было только три серьезно используемых языка: Алгол, Фортран и ПЛ/1 (который автоматом прилагался к ЕС ЭВМ). И покупалось только «серьезное» ПО.
Алгола на PC никогда не было, остается только два языка. А Си, Турбо-Паскаль и другие начали появляться на предприятии года через 3-4, но это уже совсем другая история.

     2021/12/26 18:49, Gudleifr          # 

Мы сразу начинали на PC с больших задач и Бейсик бы здесь не помог.

Заблуждение, оставшиеся от больших машин. На персоналках у пользователя был полный доступ к системе и собрать очень серьезный проект из простейших деталей было достаточно просто. Большие языки здесь были, скорее тормозом. Сейчас, кстати, даже хуже — слишком тяжеловесно ПО, с которым надо согласовывать свои программы.

     2021/12/26 19:50, kt          # 

Смотря что считать «серьезным» проектом. Наши заблуждения все время укреплялись потому, что постоянно что-то требовалось, что было в PL/1: то трехмерные массивы, то, например, гиперболический косинус для расчета объема бака, у которого часть поверхности сфера, часть — тор. Да и просто написать на том Бейсике сдвиг байта на 4 бита — веселая работа. Ведь это был всего лишь язык для начинающих, а не для реальной работы.

     2021/12/26 20:45, Gudleifr          # 

Наши заблуждения все время укреплялись потому, что постоянно что-то требовалось, что было в ПЛ/1: то трехмерные массивы, то, например, гиперболический косинус для расчета объема бака, у которого часть поверхности сфера, часть — тор.

Но для этого не нужен ЯВУ. Для этого нужны справочники по процессору и вычислительной математике. Это как с одной из моих первых производственных задач. Все было очень просто — раскидать значения фазовых сдвигов ФАР из таблиц разработчика в таблицы прошивки. У реализации на Turbo Pascal время бесперебойной работы PC-AT оказалось меньше времени работы программы. А тупая программа в кодах справилась минут за двадцать. (Правда, потом результат ещё 3 дня скидывали на перфоленту).

     2022/08/25 15:12, kt          # 

Наткнулся на сайт http://teampli.net/ Там есть впечатляющий список всяких старых поделок на тему PL/1. Языки, связанные с PL/1:
  • Интерактивные языки подчеркивают взаимодействие с пользователем. Эти языки являются интерпретируемыми и часто инкрементными компиляторами ACME, BRUIN, CPL, NICOL, RUSH
  • Учебные языки предназначены для обучения программированию и подчеркивают скорость компиляции и хорошую диагностику, а не производительность выполнения. Эти языки обычно, по крайней мере, частично интерпретируются. PL/C, PL/zero, PLUM, PLUS(2), PLUTO, SL/1, SP/k, SPL(2).
  • Системные языки предназначены для задач системного программирования, таких как программирование ОС и компиляторов. Эти компиляторы опускают функции, не полезные для системного программирования, и часто включают функции, обеспечивающие прямой доступ к базовой аппаратной архитектуре. Apple, EPL, GPL, LSD, MPL(1), MPL(2), PL/DS, PL/M, PL/P, PL/S, PL-6, PL.8, PLUS(1), SPL(1), XPL.
  • Языки специального назначения — это языковые подмножества, адаптированные для определенной цели. ESPL-1, HAL/S, MPL(3), PEARL, PL/Prophet, Sabretalk, TACPOL и, возможно, Rexx и XPL.
  • О неклассифицированных языках слишком мало известно, чтобы их классифицировать. ALECS, PARSEC.
  • Полнофункциональные компиляторы PL/I не включены в этот список.

Если взять из этого списка какой-нибудь PL/zero, то читаем:

это минимальное подмножество PL/I, предназначенное для введения в программирование. Был создан по крайней мере один фактический компилятор PL/zero.

Кеннеди, Майкл и Соломон, Мартин Б.; Структурированный PL/zero плюс PL/I; Энглвуд-Клиффс, Нью-Джерси, Прентис-Холл, 1977.

Пожалуй, вот и разгадка бесящей меня фразы "наверное, не существует ни одного компилятора, реализующего полный PL/I", которая кочует из Вики в Вику. Не существовало 45 лет назад. Но давно уже такого нет и стандарты давным-давно реализованы.

     2022/08/25 23:28, Автор сайта          # 

разгадка бесящей меня фразы "наверное, не существует ни одного компилятора, реализующего полный PL/I", которая кочует из Вики в Вику.

План действий для избавления от этой фразы:
  • выясняем, какие есть стандарты языка,
  • составляем табличку, где по горизонтали — существующие компиляторы, по вертикали — варианты стандартов (или наоборот),
  • заполняем табличку, в каждой клеточке пишем: «соответствует», «соответствует частично» или «не соответствует» (можно указать год, с которого соответствует),
  • помещаем табличку на сайт pl1.su,
  • исправляем страницу в Википедии со ссылкой на авторитетный источник (то есть pl1.su; он же авторитетный источник, не правда ли?).
Последний пункт готов взять на себя :)

А вообще странно такое утверждать, что нет ни одного соответствующего стандарту компилятора. Разве IBM в своё время не написала такой (а именно PL/1 (F) для OS/360)? Для такой авторитетной в то время компании просто странно «родить» язык и при этом отказаться от полной реализации. И можно ли в Википедии гадать на кофейной гуще («вероятно, не существует ни одного компилятора»)? Надо приводить факты со ссылками, что такие компиляторы либо существуют, либо не существуют.

P.S. Почитал английскую страницу Википедии о PL/1. Она значительно больше русской и достаточно интересна. Прямо напрашивается, чтобы русскую страницу пополнить информацией из английской. И наоборот тоже, кстати.

И ещё. В английской Википедии нет фразы «вероятно, не существует ни одного компилятора»!

     2022/08/26 11:30, kt          # 

Для такого плана действий слишком большие затраты времени )) Кроме того, (такой вот анекдот, да) ни у кого из пользователей языка, включая Робина Волвеса, нет полного текста двух стандартов. ISO требует за них $250 и всех жаба задушила.

А вот скорректировать тексты на PL1.SU, используя английскую Вики и добавить раздел "опровержение мифов" — хорошая идея. Записал в блокнотик.

     2022/08/26 23:52, Автор сайта          # 

Вот и хорошо, что предложение привело к новым идеям :) Английская страница на Вики про PL/1 мне показалась куда интереснее, чем наша. Там есть, мне думается, чем пополнить русскую страницу. И для «опровержения» тоже есть там материалы. Само опровержение можно ещё на Хабр поместить.

Обратил внимание, что в английской Вики не упомянуто, что роль и значение языка на территории СССР и стран СЭВ была куда больше, чем на родине языка. Ещё английскую страницу можно было бы пополнить информацией о «физических» типах, реализованных в Вашем компиляторе. Можно упомянуть о применении языка в российском сегменте МКС. И ссылки на «авторитетные» источники сделать на английские страницы сайта pl1.su.

     2022/09/12 11:58, kt          # 

Любопытное для меня событие, случилось вчера, 11 сентября 2022 года: некий Джон Коэн написал в https://groups.google.com/g/comp.lang.pl1/c/5fX1udOrxOM

Приближаюсь к концу создания своей [системы] LRM для подмножества G, и я рассматриваю возможности, исключенные из подмножества G, которые, по моему мнению, могли бы быть полезными для добавления в компилятор pli2c, о котором я размышляю. … Я был бы признателен за обратную связь о (кажущейся или фактической) полезности этих добавлений.

Т.е. нашелся на свете ещё человек, который занимается почти тем же, что и я. Сразу на ум пришла новелла О’Генри «Родственные души» — у двух совершенно разных людей все же нашлось общее.

Дискуссия о том, что было бы полезно вернуть в подмножество G из «полного» (или «настоящего») PL/1 тут же переросла в дискуссию, понимал ли в 1981 году комитет по стандарту подмножества, что он вообще делает. Не знаю откуда, но Коэн привел состав комитета и тех, кто оказал влияние на его работу

Technical Committee X3J1 had the following members at the time it forwarded this standard to its parent committee:

John C. Klensin, Chair
Charles G. (Chip) Nylander, Vice Chair
Fidelis N. Umeh, Secretary
Alex J. Arthur, Editor (deceased)
David R. Morey, Editor
George H. Royer, Editor
Davinder Athwal
Keith Besaw
Fred Calm
Arthur W. Coston
Andre Lacroix
Kam Mok
Kevin Mooney
Beverly Schultz
Nancy Travis
J. G. Van Stee

Others who made important contributions to this standard were:

Paul W. Abrahams
Kenneth Dritz
Andrei P. Ershov
A. Craig Franklin
Mimi Gerstell
Ev M. Greene
Richard Howells
L. Korneva
Peter Krupp
John Leffler
Howell A. (Skip) Richards
Gary Roberts
David Sahakian
W. Olin Sibert
Anthony P. Smith
Haruyuki Takeda
Richard Weaver

Ни д-ра Фрайбургхауса, ни Гарри Килдэлла не упомянуто. Вероятно, стандартизация пошла уже после первых обсуждений в 1980 году. Обращает внимание присутствие в списке академика Андрея Петровича Ершова, который, оказывается, тоже повлиял на вид инструмента, что я использую и по сей день.

     2022/09/12 23:32, Автор сайта          # 

Приближаюсь к концу создания своей [системы] LRM для подмножества G

Делается ещё один компилятор PL/1?

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

И-и-и? У Вас была эта обратная связь? Вижу, что в комментариях отметился Зимнов, а вот Ваших там нет.

Обращает внимание присутствие в списке академика Андрея Петровича Ершова

Там есть ещё один русский участник: Л. Корнева. Погуглил, оказывается Корнева Лилия Алексеевна — автор книги о стандарте PL/1.

     2022/12/17 12:56, kt          # 

Недавно на Linux.org.ru кто-то закинул вопрос «Сколько зарабатывает Pascal программист?» https://www.linux.org.ru/forum/development/17055960/page16?lastmod=1671270271778

И за пару дней накидали более 800 комментариев. Завсегдатаи даже спохватились, что, возможно, это просто стеб. Тем не менее, были попытки и всерьез отвечать. Хотя все ожидаемо опять скатилось к религиозной войне. Уж очень больное место для многих — идеальный язык. А для меня вот такие вопросы показались забавными

yu-boot (15.12.22 22:11:01 MSK)
Я два года хочу ЯП применяемый в продакшене, чтобы и присваиваивание, и сравнение было «=». В бейсике это дико приятно было, ну и может родной русский язык это диктует, говорю/думаю я «а равно б» и «если а равно б», т.е. одинаково. Мне это кажется очень естественным. Есть такой язык?

Так и хочется ответить «есть такая партия язык». Вот когда нужно всуе упомянуть язык — так не дождешься ))

     2022/12/17 14:38, Автор сайта          # 

Так и хочется ответить

Так ответьте! За правду нужно бороться! :)

Мне кажется, таких языков немало. В языке xBase было так же, как и в Бейсике.

Вообще эта тема уже поднималась. Лично мне не нравится Паскалевское обозначение для присвоения «:=». Можно, конечно, сделать ход конём и присвоение делать не справа налево, а наоборот:
b + c -> a
Тогда знак «равно» будет означать только проверку на равенство. В том же C++ проблема состоит в том, что присвоение — это операция, возвращающая значение. И проверка на равенство — это тоже операция, возвращающая значение. Во избежание двусмысленности этим операциям дали разное обозначение.

А если сделаем, что присвоение — это не операция, а оператор, который значения не возвращает? Тогда в этот код
func (a = b, c = d);
будет равнозначен не
a = b;
c = d;
func (a, c);
а
A = (a = b? true: false);
C = (c = d? true: false);
func (A, C); // A и C — значения логического типа

     2022/12/19 10:08, kt          # 

Да, конечно, я в курсе этой темы. Просто не нравится решение в виде «==». Легко ошибиться и получить другой результат. И с моей точки зрения смотрится некрасиво.

Впрочем, как говорится, "чья бы мычала". В ассемблере есть схожая проблема: команда без параметров movsb, это относительно esi/edi/ecx или rsi/rdi/rcx? Поэтому в RASN-KT для отличия удваивается первая буква мнемоники. Т.е. есть movsb и mmovsb. Привыкаешь, конечно, но в целом аналог «==».

     2022/12/19 13:33, Gudleifr          # 

Проблема «==» это не проблема обозначений. Это проблема выбора языка. PL/I, как наследник BASIC, попытался дать удобные языковые конструкции на любой пользовательский чих. Но с появлением синтаксической компиляции наличие "единого языка программы" стало анахронизмом. Стало очевидным, что в любой программе есть, по крайней мере, два языка — управления последовательностью вычислений и арифметических вычислений, имеющих абсолютно разную грамматику. В "языке управления" «==» кажется избыточным, но в "языке арифметики" это очевидный способ отличить операции адресации от логических. Как например «||» и «&&» — для различения логических и битовых. Выход не в совмещении максимально мощного языка управления с максимально мощным языком арифметики, а в возможности их разделить и создавать по отдельности "на лету", по мере написании сложной программной системы. Как в том примере работы с Win-API, требующем, по крайней мере 8-и совершенно разных, но очень простых языков, который почему-то потер местный вахтер.

     2022/12/19 14:12, kt          # 

Я всегда считал, что «==» это следствие того, что в Си присваивание имеет значение, а, например, в PL/1 — нет. Поэтому в PL/1 присваивание не может находиться внутри условия и по контексту компилятор различает один символ в двух этих случаях. Не требуется удваивания. Знак же && это другое, это команда не вычислять (или, наоборот, всегда вычислять) выражение, хотя в этой точке уже ясно, что логический нуль.

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

Также я не воспринимаю разницу между логическими и битовыми операциями, поскольку в PL/1 есть битовые строки и логические переменные — это всего лишь битовые строки длиной в один бит, а не отдельный тип и не нужно отдельных операций для этого типа.
Вообще, PL/1 пытался очень ограничить число символов исходного текста и, конечно, ничего не вышло — пришлось применять комбинации. Например использовать все 4 комбинации умножения и деления /* , */, **, //

Т.е. действительно, одних арифметических знаков совершенно недостаточно для исходного текста (т.е. языка управления). Но поскольку тогдашние телетайпы не хотели переделывать — решили использовать всякие комбинации: -> ^= ^> и прочие иероглифы из 2 знаков. Задним числом: лучше бы тогда переделали бы телетайпы ))

     2022/12/19 15:04, Gudleifr          # 

Поэтому в PL/1 присваивание не может находиться внутри условия

Ну, как показывает опыт программирования, операции с памятью — очень удобная штука для арифметических языков (не только в Си или Forth, но даже в Б3-34). Операция же присваивания для языков управления слишком слаба и искусственна. Более того, не однозначна и порождает жуткие проблемы с управлением памятью. Возможно, в языке управления удобнее иметь дело не с "переменными", а с "состояниями" и "хранилищами".

     2022/12/19 22:55, Неслучайный читатель          # 

Поэтому в PL/1 присваивание не может находиться внутри условия

А внутри других конструкций PL/1 может? Это код будет работать?
 PUT(VAR=VALUE);
Чтобы два в одном, сперва присвоить, а потом напечатать?

     2022/12/20 00:10, Автор сайта          # 

Если операции присваивания дать обозначение «<-» или «->», то какое обозначение придумать для операций вида «+=», «*=», «&=»? Всё-таки в программах присваивают чаще, чем проверяют на равенство. Если делать выбор, какой операции выгоднее выделить обозначение «=», то выбор надо делать в пользу присваивания. Ну а для проверки на равенство можно было бы попробовать «=?». Как вы находите такой вариант?

решили использовать всякие комбинации: -> ^= ^> и прочие иероглифы из 2 знаков ... лучше бы тогда переделали бы телетайпы

Тогда бы на клавиатурах было очень много клавиш. На весь Юникод клавиш не хватит.

операции с памятью — очень удобная штука ... Операция же присваивания для языков управления слишком слаба и искусственна.

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

     2022/12/20 00:17, Gudleifr          # 

В этом видится логическое противоречие

Именно, т.к. Вы хотите один язык и для управления программой, и для арифметики.

     2022/12/20 06:11, kt          # 

А внутри других конструкций PL/1 может? Это код будет работать?

сработает как оператор сравнения. Так как можно писать x=y=z; где x строка в 1 бит (логическая переменная). Поэтому
put data(var=value);
напишет
var=value = '1'b;

     2022/12/20 20:04, MihalNik          # 

Лично мне не нравится Паскалевское обозначение для присвоения «:=».

Грамматика Паскаля от замены ":=" на "=" не сломается. Перековать синтаксис рекурсивным спуском — несколько сотен строк кода. Дело же не в этом.

Я два года хочу ЯП применяемый в продакшене, чтобы и присваиваивание, и сравнение было «=»

Люди, выкатывая свои очередные хотелки, напрочь забывают от последствиях масштабирования. А они готовы объяснить каждому школьнику, что "а = б" не равносильно "б = а"? Или вот это:

можно писать x=y=z; где x строка в 1 бит (логическая переменная)

Когда в среднем на ученика приходится пара-тройка минут в неделю.

     2022/12/20 21:54, kt          # 

Думаю, школьники здесь ни при чем. Школьник может спросить о Си, зачем два знака плюс подряд? Число же уже и так положительное? Да, часто запись похожа на уравнения математики, но это не уравнения. Новичок это быстро преодолевает. Особенность PL/1, что если это не присваивание, то, значит, сравнение.

Поэтому x=y=z; на самом деле присваивание в переменную "x" результата сравнения "y" с "z". И мы реально пользуемся такой конструкцией, неким аналогом тернарного оператора. Например
окно_свернуто=(w_param=1)
Но возникают и ловушки, когда машинально пишут
if 1<x<2 then... 

у каждого свои недостатки (с) фильм "В джазе только девушки"

     2022/12/24 17:20, MihalNik          # 

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

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

Думаю, школьники здесь ни при чем. Школьник может спросить о Си, зачем два знака плюс подряд? Число же уже и так положительное?

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

     2022/12/24 19:26, Gudleifr          # 

Поэтому школьникам не преподают Си в рамках образовательной программы

Ориентация преподавания на "высокоуровневых языков" порождает две проблемы:
  1. Современные ИТ-шники совершенно не знают математических основ построения компьютера. Они представляют его суперкалькулятором с миллионом кнопок на все случаи жизни. И главным шаманством считают запоминание этих кнопок и умение собирать их в бусы.
  2. Современные ИТ-шники уверены, что настоящие языки пишут секретные надмозги, как и настоящие программы на настоящих языках. А им простым ИТ-шникам — вечно "ключи подавать".

     2022/12/25 10:44, Неслучайный читатель          # 

Поэтому школьникам не преподают Си в рамках образовательной программы

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

Спросил как-то одного студента, у которого первым языком программирования был изучаемый в вузе Си. Осторожно так поинтересовался, понимает ли он, что знак равенства в Си ассиметричен, поскольку подразумевает не равенство, а присвоение. Он на это обиделся, мол, за дурачка что ли держишь, естественно всё понято, ничего сложного нет.

Современные ИТ-шники совершенно не знают математических основ построения компьютера.

Все айтишники разные, не надо всех под одну гребёнку. Есть один знакомый студент, который утверждает, что Си — это компилятор, а Питон — интерпретатор. И ему хоть кол на голове теши, он не разделяет язык и его реализацию. Что Си можно сделать интерпретатором, а Питон компилятором. Видимо, обучение было избавлено от «лишних деталей», знания заменили стереотипами. Но встречал и умниц, которым даже завидуешь: ну надо же, я в его годы столько знаний не имел.

     2022/12/25 11:05, Gudleifr          # 

Есть один знакомый студент, который утверждает, что Си — это компилятор, а Питон — интерпретатор.

И он прав, потому, что реализованные "наоборот", они перестанут обладать своими характеристическими свойствами. Интерпретатор Си перестанет быть средством затыкания дыр в 'NIXах, а на компилируемом Питоне нельзя будет начинать "роман" словами "Козел вышел на балкон полюбоваться закатом", и только на 600-й странице указать, что "козел" — погоняло завхоза, "балкон" — ограждение реактора, а "закат"... да черт, с ним с "закатом"...

     2022/12/25 16:00, Автор сайта          # 

Как Вы не любите современных ИТ-шников. Я уже писал:

Чего Вам действительно не хватает, так это оптимизма. «С таким настроением Вы слона не продадите».

Могу ещё такое добавить:

Передаём гороскоп на завтра. У оптимистов всё будет плохо. Но они этого не заметят. У пессимистов всё будет хорошо. Но они этого не оценят.

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

Язык — это то, что описано в стандарте. Если «характеристические свойства» там описаны, значит так и должно быть. Всё остальное — от лукавого. У Си, к примеру, стандарт не требует наличия компилятора.

     2022/12/25 16:25, Gudleifr          # 

Как Вы не любите современных ИТ-шников

От них никакой пользы, кроме вреда.

У Си, к примеру, стандарт не требует наличия компилятора

А кто-то из пишущих на Си его читал?

     2022/12/25 17:34, Gudleifr          # 

P.S. Я, по сути, знаком только со стандартами на два языка: Си и FORTH. И в обоих случаях мы имеем дело с головотяпством.
  1. Оба типа стандартов были созданы после окончания активной жизни языков.
  2. Оба противоречили способу применения языков.
  3. Оба исключали дальнейшее развитие языков.

     2022/12/28 16:18, void          # 

Есть один знакомый студент, который утверждает, что Си — это компилятор, а Питон — интерпретатор. И ему хоть кол на голове теши, он не разделяет язык и его реализацию. Что Си можно сделать интерпретатором, а Питон компилятором.

... И он прав, потому что стандарт на язык определяется реализацией (по крайней мере, в таких случаях как С, С++, Питон). Что эти каноничные реализации — именно такие. А то что "можно сделать" по другому — означает, что получится по сути другой язык. Например, "компилируемый Питон". Много кто пытался сделать реализацию на LLVM, да и вот например под JVM: GraalVM, например Bazel — средство сборки с "конфигами на Питон", то есть: своей компилируемой в JVM реализацией питоноподобного языка. Ну или: IronPython под CLR .NET, да и вот например Nim тоже немного на него похож.

Но язык по сути динамический, а с компилируемой реализацией выходит что нужно перетащить туда для совместимости все runtime особенности, ну например, интроспекции и объектные обёртки и тот же GIL. Кстати, тот же CPython и т.п. — по сути минималистичное компилируемое подмножество, а не динамичный интерпретируемый язык и среда.

Ещё примеры: "интерпретируемый Си". Их несколько реализаций: Ch, Pawn, Pike (бывший LPC). Есть как платные, так и открытые. Наиболее открытой, и богатой библиотеками и модулями является, похоже Pike. Там, кстати, через FFI можно задействовать C ABI и внешние библиотеки, да и модули есть, компилированные на Си. То есть, язык наиболее похож на какую-нибудь Lua (у которой есть компилируемая Terra). Ещё было несколько opensource реализаций интерпретатора C-REPL на LLVM, кажется. Но Pike довольно практичный и полноценный по модулям.

     2022/12/28 16:44, void          # 

Оба типа стандартов были созданы после окончания активной жизни языков.

Скорее, здесь тоже как с С++ случай стандартизации "де-факто", "эволюционного" как бы развития (если это вообще развитие) по принципу: "я его слепила из того что было, а потом объявила эту реализацию как есть стандартом". В отличие от более других языков, где сначала появляется формальное и формально верифицируемое определение на уровне стандарта, потом — соответствующая ему реализация.

Например, вот ISO ISLISP. В определении языка в стандарте есть "стандартный исполнитель", "стандартный процессор" и дальнейшее описание языка есть в его терминах (как реализация интерпретатора, так и компилятора). В результате имеем довольно компактное описание семантики языка, среды времени выполнения и компиляции. В отличие от того же Common Lisp-а, который появился как пиджин, Common Language и прочий волапюк на примере других уже устоявшихся реализаций языка и среды: InterLisp и BBN Lisp, MDL и MacLisp, Macsyma и Reduce, Portable Standard Lisp, ну и те же реализации лисп-машин: ZetaLisp, LMI Lisp и т.п. Не считая диалекты схемы, и прочие LeLisp/EuLisp.

Richart Gabriel на https://www.dreamsongs.com/WorseIsBetter.html (там обзор, подробнее в https://www.dreamsongs.com/RiseOfWorseIsBetter.html и в https://www.dreamsongs.com/WIB.html) пишет про этот процесс стандартизации в эссе про подходы к проектированию: "правильные вещи" vs. "чем хуже, тем лучше".

Unix and C are the ultimate computer viruses.

A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in small machines and large ones, and the code will be portable because it is written on top of a virus.

It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.

The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.

Что поразительно, в середине 80 думали что не останется других, более низкоуровневых языков — чем Ада и Common Lisp. Потому что зачем нужны низкоуровневые, когда есть такое богатство. В этом смысле Ричард Гэбриэл с "чем хуже, тем лучше" оказался реалистом. Ещё ранее, кажется, в той же "Unix Hater's handbook" пришли к тому же выводу:

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

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

В Forth, если бы стандартизация шла не по пути FigForth->ANS Forth-> Forth 2020 и т.п., а например, формализуя семантику внутреннего интерпретатора через такого абстрактного исполнителя, тоже могли бы получить в итоге более компактное описание стандарта. В пределе мог бы получиться какой-то очередной конкатенативный, вроде Retro форта и его Ngaro VM или 8th или того же Factor.

     2022/12/28 17:07, Gudleifr          # 

В стандарте Си, кстати, тоже появляется "абстрактный исполнитель" с соответствующей "моделью памяти"

Нет, он там был изначально. См. компиляцию с ключом -S.

Впоследствии компиляторы Си стали переписывать

Они к тому времени уж вымерли.

старые программы перестали компилироваться

K&R прекрасно компилируется gcc. Тут речь, скорее, о "программистах", пытающихся воспринимать Си как ограниченный Си++.

формализуя семантику внутреннего интерпретатора через такого абстрактного исполнителя

Абстрактный исполнитель для FORTH не нужен.

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

Это никому не надо. С одной стороны "язык FORTH" — это чистая условность, с другой — с появлением UNIX появились более удобные компиляторы компиляторов.

     2022/12/28 17:12, void          # 

Интерпретатор Си перестанет быть средством затыкания дыр в 'NIXах

Оригинальный браузер Opera и его движок, кажется, как раз был раскручен из реализации на Pike. Точно на Pike (ранее LPC) там писали свою реализацию кеширующего прокси-сервера, и мелкую автоматизацию. Взяли "интерпретируемый Си", поэкспериментировали с макетами — получился движок. Затем взяли и откомпилировали большую часть кода, и некоторые куски переписали на обычном Си, а не интерпретируемом Pike. Получился браузер. В общем, дыры можно затыкать не только на Perl или Python.

С другой стороны, с той же целью могли бы взять какую-нибудь Ada и интепретируемую Ada (AdaScript, SparForte): примеры кода https://github.com/kburtch/SparForte/tree/master/examples проект https://github.com/kburtch/SparForte, сайт https://www.sparforte.com/ книга The Big Online Book of Linux Ada Programming http://www.pegasoft.ca/boblap.html

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

     2022/12/28 17:19, void          # 

См. компиляцию с ключом -S.

... и я увижу ассемблер? Нет, это не весь "абстрактный исполнитель". Абстрактного исполнителя почти не было в pcc и kencc и K&R реализациях, он и его модель памяти появились ближе к ANSI C89 ... и хорошо, что вообще появились. Плохо, что не настолько формально как Схеме или Аде.

     2022/12/28 17:35, Gudleifr          # 

В общем, дыры можно затыкать не только на Perl или Python

На них нельзя писать системные приблуды сравнимые по простоте и удобству с исходными командами ОС.

на Си, да даже Расте — а не той же Аде...

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

Нет, это не весь "абстрактный исполнитель"

Изначально — весь. Все "библиотеки" входили не в Си, а в UNIX. И было это хорошо.

     2023/02/05 11:26, IP: 46.50.195.42          # 

А тем временем жизнь продолжается :)
1 Feb, 2023: Iron Spring PL/I compiler 1.0.0 released
http://www.iron-spring.com/news.html

     2023/02/05 14:40, Автор сайта          # 

Интересно, сколько активных пользователей у PL/1? Просто любопытно. Хотя я уверен, что ответа не получу :)

Посмотрел рейтинг Tiobe, PL/1 там на позициях от 51 до 100. На каком конкретно — не понятно, потому что позиции от 51 до 100 в алфавитном порядке. Соседями по рейтингу являются вполне достойные языки: Clojure, Common Lisp, Elixir, Erlang, Forth, Modula-2, Tcl, VBScript, VHDL. Впрочем, всё равно это средняя температура по больнице.

     2023/02/05 16:43, kt          # 

Кроме нескольких десятков любителей по всему миру, ещё есть сотрудники IBM, использующие язык для "внутреннего" ПО этой фирмы и для поддержания многочисленного легаси. Почти все это касается компилятора IBM и сайта teampli.net

Самый активный из участников Робин Волвес, наверное, мог бы сосчитать. Оптимистичная оценка 200 — 300 человек.

     2023/02/08 19:11, kt          # 

Опять PL/1 обидели. Ну что ты будешь делать! Листаю солидную книгу «Компиляторы: принципы, технологии и инструментарий». Второе издание. Альфред В. Ахо, Моника С. Лам, Рави Сети, Джеффри Д. Ульман ISBN-978-5-8459-1349-4, 2008 год. 1184 страницы!

Чаще упоминают Фортран, Кобол, Лисп и Си. Но вот на странице 164 читаю:

«Например, некоторые языки наподобие PL/I не рассматривают ключевые слова как зарезервированные; это значит, что можно использовать идентификаторы с именами, совпадающими с ключевыми словами наподобие DECLARE. Если лексический анализатор встречает исходный текст программы на языке программирования PL/I, который начинается с DECLARE (ARG1, ARG2,…, он не в состоянии определить, является ли DECLARE ключевым словом, а ARG1 и далее — объявленными переменными, или это процедура с именем DECLARE и её аргументы. По этой причине современные языки программирования тяготеют к резервированию своих ключевых слов».

Это упоминание всуе языка, у которого с самого начала (1963) синтаксис как раз однозначный, поскольку весь исходный текст (за исключением метки и одного нюанса присваивания) всегда имеет одинаковую структуру всех элементов: ключевое слово, тело, точка с запятой.

Если вдруг назвали процедуру или (функцию) именем DECLARE, то она будет или внутри выражения или вызываться оператором CALL. Таким образом, лексический анализатор не испытывает затруднений. И в примере в книге это описание, а вызов будет CALL DECLARE(ARG1,… Можно назвать процедуру CALL и её вызов будет тогда CALL CALL. Разобрав первый CALL как ключевое слово, компилятор следующие лексемы (в том числе и CALL) уже трактует как идентификаторы. Стыдно авторам этого не знать, раз уж они вспомнили PL/1.

P.S. Сделав у себя CALL необязательным, я немого усложнил жизнь компилятору. Но на практике ничего страшного не произошло. Текст нормально разбирается. Единственное отличие — ошибка неописанной переменной превратилась в сообщение «это не процедура».

     2023/02/08 22:42, Автор сайта          # 

Нашлась проруха на старуху. «Тщательней надо, ребята». Альфреду Ахо — 81 год, о возрасте Моники Лам в Википедии не пишут (дама, всё-таки), но стала бакалавром в 1980 году, Рави Сети — 75 лет, Джеффри Ульману — 80 лет. Все живы, всем можно написать и попросить исправить ошибку.

Я однажды имел наглость написать руководителю одного стартапа, финансируемого DARPA, да ещё по-русски (имя-фамилия вполне могли быть славянскими). Ответил! Сказал, что не понимает по-русски. Повторил ему по-английски. Ответил! Ответил на тот вопрос, который я ему задал — о деталях его проекта. Так что не боги горшки обжигают. Тем более, что Вы указываете на ошибку. И Ваши слова имеют вес хотя бы потому, что Вы разработчик компилятора этого языка.

     2023/03/03 17:07, kiv(jobless)          # 

Проблема с pl1.su. Я уже задавал вопрос про лицензию и доступность. Надумал тут 40-летний технический долг погасить, была провальная программка на ПЛ/1 меж двух успешных. Но если доступность для других под вопросом, то не стоит и начинать.

     2023/03/03 23:13, Автор сайта          # 

Не понятно, что с сайтом. Он пингуется, но пишет про проблемы с WordPress. Видимо, сайт написан на этой CMS. И Дмитрий Юрьевич не в курсе причин — сайт не его. Будем ждать, когда хозяин очнётся.

     2023/03/04 00:16, Ильдар          # 

Надумал тут 40-летний технический долг погасить

Курсовую работу что ли не сдал? Или дипломную?

     2023/03/04 07:00, kiv(jobless)          # 

С дипломом (1983г) на тему "Центр коммутации сообщений. Анализ методов маршрутизации" как раз всё было замечательно. ))) А вот первое, за что зарплату уже платили, провалил, до сих пор стыдно ))) Реабилитировался на последнем, что на ПЛ/1 разрабатывал. После внедрения в середине 80-х без меня работало до смерти машины, на которой стартовало.

Анализ испытаний http://militaryrussia.ru/blog/topic-604.html

     2023/03/04 08:10, kiv(jobless)          # 

Что то ящик не принимает почту mail@compiler.su. Пишу здесь. Помогите связаться с Д.Ю.Караваев

     2023/03/04 16:31, kt          # 

Заработал PL1.SU. Виноват автоматически обновившийся 1 марта плагин, а не какая-то лицензия.

     2023/03/04 19:39, kiv(jobless)          # 

Напрасно вы с таким раздражением о лицензии. Вот пример одного из авторских проектов-инструментов, который я использую:
http://phix.x10.mx/
http://phix.x10.mx/licence.php
Есть место, где можно как минимум по смотреть новости(на pl1.su отрывки из обрывков)
https://openeuphoria.org/forum/137643.wc?last_id=137685
При скачивании получаешь редми,документацию, протокол изменений, и т.д. и т.п.
http://phix.x10.mx/download.php
И в конце концов я могу задать вопрос автору
https://openeuphoria.org/user/profile/petelomax.wc
...
Ну и с некоторых пор
https://github.com/petelomax
там нет релизного, но по участвовать в тестировании возможно.

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

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

С PL/1-kt при обезличенном сайте создаётся впечатление, что как мы не знали много лет о существовании, так и в любой момент перестанем знать о дальнейшей судьбе.

     2023/03/04 22:26, kt          # 

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

Поскольку основная работа продолжается — продолжается и доработка этих средств программирования. И постоянно тестируется на наших же программах. Чтобы все это в одночасье не пропало (после ухода на пенсию) и был организован раздел на PL1.SU. Там есть и актуальная документация и примеры программ.

Исправления идут часто, но обычно на самом низком уровне машинных команд, ведь большая часть исходных текстов — на ассемблере. Вряд ли это интересно (и понятно) большинству потенциальных пользователей. Поэтому в «новостях» указывается, что-то более существенное.

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

     2023/03/05 06:46, kiv(jobless)          # 

Вряд ли это интересно (и понятно) большинству потенциальных пользователей.

И кто же по вашему этот пользователь, если ему, как вы считаете, не интересно, да ещё и не понятно?

До сбоя на сайте доступна была версия от 22 февраля, сейчас от 4 марта. Это одно и тоже или это разное, если разное, то что изменилось? Я не понимаю, кто этим вслепую по-вашему будет пользоваться.

А уж фраза про пропажу при выходе на пенсию вообще выбивает из колеb. Это что не авторский код, а "утечка" с "места работы"?

     2023/03/05 10:30, kt          # 

И кто же по вашему этот пользователь, если ему, как вы считаете, не интересно, да ещё и не понятно?

Имеется ввиду интерес к мелким исправлениям. Например, выяснилось, что если вызывается WinApi без параметров, то функция иногда все равно требует выделения стека для внутренних данных (почему в этом случае она сама не выделяет стек непонятно). Обратились к такой функции WiApi — она то работает, то нет. Добавили в компилятор команду SUB RSP,32. Но на уровне исходного текста врограммы ничего не меняется. Зачем же морочить людям голову описанием изменения, которое для них прозрачно?

Другой пример, Для оптимизации используется иногда малая разность адресов (https://habr.com/ru/post/663960/). Но из-за ляпсуса была упущена проверка на «внешние» переменные. Ну и зачем описывать «новость», что в таком-то модуле я поставил команду проверки, но забыл условный переход (в этот момент отвлекли) и получилась плавающая ошибка? Да мне и самому это уже не важно — исправил, изменил дату сборки и всё. Отметил во внутреннем комментарии с датой.

До сбоя на сайте доступна была версия от 22 февраля, сейчас от 4 марта.
Это одно и тоже или это разное, если разное, то что изменилось.
Я не понимаю, кто этим в слепую по вашему будет пользоваться.

Из-за отказа сайта попробовали откатить до 1 февраля, но не помогло. В данном случае все сохранилось, кроме счетчиков скачиваний (переживем как-нибудь). А тут очередные поправки подоспели в PLINK64.EXE. Его сразу и обновили. Т.е. на сайте всегда самая последняя версия. За этим следим.

А уж фраза про пропажу при выходе на пенсию вообще выбивает из колей. Это что не авторский код а "утечка" с "места работы"?

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

     2023/03/05 11:03, kiv(jobless)          # 

Вот другой проект, в отличие от Phix, проприетарный, исходники закрыты и планов по открытию нет. На сегодня, во всяком случае. Но по каждой бете подробный отчёт: https://www.purebasic.fr/english/viewtopic.php?t=80551 На сегодня два бакэнда: Asm и Си (т.е. для автора — это как и для Вас своеобразный Макроассемблер (с версии 6.0 МакроСи в угоду движению на бурно растущие другие архитектуры). И все правки в документации раньше были доступны в svn, сейчас в git.

Это я о том, что не верю в то, что свёрстанная документация в прошлые годы в точности соответствует текущему моменту.

ИМХО. Если ваша публикация (PL/1-kt) не изменит отношение к потенциальным пользователям, то смысла в этом НОЛЬ целых НОЛЬ десятых. Инструмент по прежнему останется интересен только Вам. Для остальных эт просто информация, что он существует, но не больше.

P.S. И поверьте, я всё это пишу с нескрываемым уважением к вашему труду.

     2023/03/05 14:32, Автор сайта          # 

С PL/1-kt при обезличенном сайте создаётся впечатление, что как мы не знали много лет о существовании, так и в любой момент перестанем знать о дальнейшей судьбе.

ИМХО. Если ваша публикация (PL/1-kt) не изменит отношение к потенциальным пользователям, то смысла в этом НОЛЬ целых НОЛЬ десятых. Инструмент по прежнему останется интересен только Вам. Для остальных эт просто информация, что он существует, но не больше.

Да, меня тоже удивляло отсутствие собственного сайта. Это вопрос репутации и доверия. Тем более можно обойтись малой кровью, если не хочется тратить время и силы — полно разных конструкторов. Это можно сделать даже при полном незнании вэб-технологий. Ведь было написано немало статей на тему PL/1, и на это не было жаль тратить время. А вот пожертвовать одной статьёй и сэкономленное время потратить на собственный сайт — такой вариант почему-то не рассматривается. Я даже уверен, что найдутся добровольные помощники. Просто надо объявить о своём желании и общими мазками обрисовать свои хотелки. Но

Каждый пишет, как он слышит.
Каждый слышит, как он дышит.

P.S. И поверьте, я всё это пишу с нескрываемым уважением к вашему труду.

Готов подписаться под каждым словом.

     2023/03/05 20:27, kt          # 

Не понимаю, что значит «обезличенный сайт» и как изменить отношение к потенциальным пользователям? Сайт PL1.SU имеет отличное, на мой взгляд, имя для такой темы. Раздел PL/1-KT на этом сайте я считаю своим: я сам вношу туда данные, меняюю их, отслеживаю последнюю версию компилятора. Даже сам обращаюсь в техподдержку, когда сайт ломается.

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

Рассказано, откуда все появилось, есть примеры и даже пример оформления текста. Что же тут «безличного» для потенциальным пользователей? Нет гарантии, что компилятор не исчезнет? Так такую гарантию даже для Windows дать сейчас нельзя.

     2023/03/05 23:38, Ильдар          # 

что значит «обезличенный сайт»?

Сайт PL1.SU имеет отличное, на мой взгляд, имя для такой темы.

Представьте, что у АвтоВАЗа нет собственного сайта. Но зато есть сайт с отличным именем автомобили.рф, где пишут про его машины наряду с Камазами, Уазами и Газелями. Поэтому говорят, что нет своего лица.

Это вопрос репутации и доверия.

Когда вкладываешь куда-то деньги, то отсутствие телефона, электронной почты или сайта сразу отбивает желание инвестировать. Выбор инструмента для разработки — это тоже инвестиция, потому что тратишь время на изучение особенностей компилятора. Разрабатываешь тоже с учётом особенностей. Захочется ли складывать яйца в сомнительную корзину?

     2023/03/06 07:48, kiv(jobless)          # 

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

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

С надеждой и уважением.

VTO 25.06.2019 02:37 Хорошо бы указывать, что изменилось...

Вам ещё в 19-м году об этом на сайте писали. И за примером далеко ходить не нужно: http://www.iron-spring.com/index.html

     2023/03/06 12:39, kt          # 

Действительно, каждый пишет, как он слышит. Я пишу, что исправления, большей частью касаются внутренних вещей, и пользователям напрямую их применить не получится, а мне пишут, что нужно указывать, что изменилось. А пример iron-spring здесь не показателен. Во-первых, это проект, который закончат правнуки автора лет через 50, а во-вторых, он расширяет свой транслятор до возможностей IBM, т.е. как раз все эти изменения — на уровне языка и напрямую могут применяться в исходных текстах. Такие исправления у меня очень редкие и я их обязательно указываю. Но не указываю поток мелких внутренних исправлений, которые не влияют на совместимость.

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

На мой взгляд, здесь и двух мнений быть не может. ПО ВСЕГДА должно быть перекомпилировано последней версией. Мы всегда так делаем. Иначе как искать ошибки в компиляторе? Держать репозиторий всех когда-то выложенных версий? Непродуктивно. Кроме этого, на мой взгляд, все привыкли к вопиющим безобразиям, когда очередной «новый завет» отменяет «ветхий завет» и старые программы перестают компилироваться. Это свидетельствует о незрелости принимаемых решений или о попытках вылечить родовые травмы. Для PL/1 это нехарактерно, он устаканился за многие десятилетия.

     2023/03/06 13:34, kiv(jobless)          # 

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

С какой целью, вы решили его публиковать — мне и думаю не только мне так и не стало понятней. Т.е. для других давно принято публиковать по-другому и примеров я привёл массу.

Это последнее, что я пишу в этой ветке. Извините за беспокойство. С уважением.

     2023/03/06 22:02, Автор сайта          # 

У всех сторон дискуссии аргументы убедительны. Самый точный прогноз у синоптиков звучит так: «завтра будет так же, как и сегодня» — он верен в 80% случаев. Ну и здесь я готов дать такой же прогноз: «завтра будет так же, как и сегодня». В чём-то Д.Ю. прав. стандарт языка настолько постоянен и неизменен, что самой важной новостью является «компилятор в ещё большей степени соответствует стандарту». Что касается отсутствия собственного сайта, ну так это чистая психология — приучили людей, что на каждый чих создаётся сайт.

     2023/03/06 23:39, Бурановский дедушка          # 

после ухода на пенсию

А мне ситуация видится ещё в другом ракурсе. Когда позади большая часть жизни, поневоле задумываешься, а оставил ли ты свой след на земле? Будет обидно, если дело всей жизни ненадолго переживёт своего создателя. Нужны творческие наследники, которым можно было бы передать дело. Есть ли они? Но ещё нужно быть уверенным, что PL/1 кому-то действительно нужен.

     2023/03/07 00:12, MZN          # 

Здесь написано много правильных вещей. Но все авторы делают грубую ошибку, причем ещё и противоречат сами себе, того не замечая. Они пишут это ЗДЕСЬ! Отзыв на статью из журнала А вы будете публиковать в журнале В? Впрочем, вина тут и автора компилятора тоже есть.

     2023/03/08 14:07, kt          # 

оставил ли ты свой след на земле?

Вы правы, это очень сильная мотивация. В моем случае она усугубляется вопросами руководства: а кто будет дорабатывать ПО для новых условий и сред, и, главное, кто будет потом сопровождать все это лет 10-15-20? Конечно, речь не идет о критичном ПО типа системы управления — там исполнителей хватает, а всего лишь о прикладной программе, к которой все привыкли за эти десятилетия. Здесь с творческими наследниками не очень. Есть молодые и умные и исполнительные, но не считающие программирование в целом интересной деятельностью.

А сам по себе PL/1 (как и любой другой инструмент) не нужен. Он требуется лишь в применении к чему-то. Поэтому это не главное дело моей жизни, но очень большая её опора. И мне будет очень жаль, если столько прекрасных находок и решений просто пропадут и будущие пользователи (как и сегодняшние) будут продолжать писать статьи на Хабре «Как ввести в Питоне квадратную матрицу?»

Кстати о Хабре. Там обсуждалась и статья «Столетний язык — какой он» (https://habr.com/ru/company/cloud4y/blog/715668/). Общее мнение — Фортран отметит столетие. Но я считаю, что это (если) произойдет, то только в 2090 году. Поскольку Фортран-1969 и Фортран-1990 — это очень большая разница. А вот сравнение PL/1- 1969 и PL/1-2023 вызывает в памяти цитату из «Формулы любви»: «за последние 200 лет, что я у него служу — он ничуть не изменился». Так, что это инструмент если не на все времена, то на очень большой период.

Они пишут это ЗДЕСЬ!

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

     2023/03/08 23:50, Автор сайта          # 

MZN

Вчера вообще не въехал, о чём это Вы. Даже подумалось, что спам. Но стирать не стал. Но после слов Д.Ю. «У нас надо регистрироваться» я понял, что идёт речь о сайте pl1.su и о том, что обсуждать PL/1 надо там. Предположу, что Вы владелец этого сайта :) Что я могу сказать Вам? Вы проиграли конкуренцию! :)

Честно говоря, иногда бываю на этом сайте и пытаюсь что-то читать. Но терпения хватает ненадолго — глаза жалко. Когда на чёрном фоне дважды что-то написано (один раз собственно текст, второй раз — как часть фона), то читать это трудно. Не сочтите за нескромность, но посоветовал бы сменить дизайн сайта. Наверно тому, кто его придумал, он кажется ностальгическим, напоминающим времена ЕС ЭВМ. На самом деле это не так. Бумага АЦПУ была белая, боковая перфорация на этом фоне была тёмная. Консоль заправлялась бумагой с коричневым оттенком без боковой перфорации. Самые распространённые дисплеи имели светло-зелёные символы на чёрном фоне, менее распространённые — светлые символы серо-голубого цвета (как в телевизоре), но все дисплеи были без перфорации по бокам. Тогда что из ЕС ЭВМ имело светлые буквы на чёрном фоне и светлую перфорацию по бокам? Ничто.

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

kt

Фортран-1969 и Фортран-1990 — это очень большая разница. А вот ... PL/1- 1969 и PL/1-2023

Получается, что Фортран эволюционирует, а PL/1 — нет. Выходит, что Фортран более жизнеспособен?

     2023/03/09 05:57, kt          # 

Или при создании PL/1 учли недостатки Фортрана ))

     2023/03/12 15:12, Бурановский дедушка          # 

А сам по себе PL/1 (как и любой другой инструмент) не нужен. Он требуется лишь в применении к чему-то. Поэтому это не главное дело моей жизни, но очень большая её опора.

Утрирую, но представьте, если бы Пушкин сказал: «Литературное творчество — не главное дело в моей жизни. Главное — служба в архиве МИДа». ¯\_(ツ)_/¯

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

У каждого свои вкусы, не всем программирование интересно. Но чтобы всем? ¯\_(ツ)_/¯

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

По Вашим словам, Вы не можете кому-то передать своё дело в силу Ваших уникальных компетенций (знание языка, знание компилятора и опыт его разработки). Если судьба разработки Вам не безразлична, то что-то надо делать. Для начала, наверное, найти тех, кто нуждается в компиляторе. Впрочем, Вам виднее.

     2023/03/13 11:03, kt          # 

если бы Пушкин сказал:

"Евгений Онегин" не главное мое дело, но спутник по жизни.

     2023/03/16 19:13, kt          # 

На Хабре появилась статья по истории Фортрана (https://habr.com/ru/post/722834/), где — редкий случай! — упомянули PL/1 не всуе:

В 1978 году американские военные выкатили свой стандарт MIL-STD-1753, стандартизующий расширения Фортрана 77, сделанные компьютерными фирмами, в основном CDC и IBM. Среди этих расширений был структурный оператор DO, заканчивавшийся операторной скобкой END DO, оператор DO WHILE, операторы CYCLE и EXIT для управления выполнением цикла и операторIMPLICIT NONE для отмены неявного описания переменных по первой букве. Всё это можно было рассматривать, как начало облагораживающего влияния на Фортран языка PL/I.

Но увы, этого не хватило для ухода с Фортрана))

     2023/03/17 14:02, Автор сайта          # 

Интересная статья.

Когда умрёт последний программист на $(вашем любимом языке), его тело отвезут на кладбище на катафалке, конструкция которого будет рассчитана на Фортране, а счёт на организацию похорон сформирует программа, написанная на Коболе (Старинная американская мудрость).

5 баллов!

команда из 10 программистов под руководством Бэкуса разработала язык Фортран и первый компилятор для машины IBM 704, представив первые результаты в 1954 году и затратив на разработку 18 человеко-лет.

В какой-то литературе читал, что 17 человеко-лет. Где-то была ошибка округления.

хотя Дейкстра, разумеется, критиковал его [Фортран], как и вообще всё, в чём он или его друзья не имели личного интереса

Неужели и тут откаты?! Или Дейкстра — Навальный от программирования? Неожиданный взгляд на Дейкстру. Я как-то всё время думал, что его устремления связаны исключительно с наукой, а тут про «личный интерес». Покушаясь на его учение, думал, что это его личное мнение, не связанной с «интересом».

     2023/03/27 10:42, ChatGPT отвечает          # 

Вопрос ChatGPT, ниже ответ:

Почему язык программирования PL/1 так мало востребован? Что нужно сделать, чтобы он стал популярнее? Какими дополнительными средствами и инструментами должен быть дополнен компилятор PL/1, чтобы язык стал популярен у программистов?

Существует несколько причин, по которым язык программирования PL/1 не так популярен, как другие языки, например, Java или Python:
  • Устаревшая технология. PL/1 был разработан в 1964 году и с тех пор многие языки программирования появились и развивались, что сделало его менее привлекательным для разработки новых приложений.
  • Недостаточно развитой экосистемы. PL/1 не имеет многих интегрированных сред разработки, которые делают разработку на других языках более привлекательной.
  • Сложность и размер языка. PL/1 имеет много различных функций и операторов, что делает его сложным для изучения и использования, что также может отталкивать потенциальных программистов.
Чтобы сделать PL/1 более популярным, можно принять следующие меры:
  • Обновление языка. Разработчики могут обновить PL/1, добавив новые функции и улучшения, что сделало бы его более привлекательным для использования.
  • Поддержка для современных экосистем. Разработчики могут создать интегрированные среды разработки, которые поддерживают PL/1, что сделало бы его более доступным для разработчиков.
  • Разработка ресурсов и сообщества. Создание онлайн-курсов, руководств и сообщества, ориентированных на PL/1 могут сделать язык более доступным для создателей приложений.
Дополнительные инструменты, которые могут расширить возможности PL/1, могут включать:
  • Библиотеки функций. PL/1 может быть расширен путем добавления библиотек функций, что сделало бы его более мощным.
  • Инструменты автоматизации. Инструменты автоматизации, такие как средства отладки и тестирования, могут помочь разработчикам ускорить и упростить разработку на PL/1.
  • Интеграция с другими языками. Добавление возможности для PL/1 взаимодействовать с другими языками программирования, такими как Java, может сделать его более универсальным и полезным для создателей приложений.

     2023/03/27 12:28, kt          # 

На мой взгляд — это просто продвинутый попугай.

PL/1 имеет много различных функций и операторов, что делает его сложным для изучения и использования

как исправить этот недостаток?

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

Кстати, на вопрос "почему перед гостиницей Космос стоит памятник Де Голлю?", чат отвечал, что Де Голль внес огромный вклад в развитие космоса. Он был первым космонавтом и первым человеком, высадившимся на Луне. Наверное, уже исправили, но как не было ИИ, так и не появилось.

     2023/03/27 12:58, ChatGPT отвечает          # 

Продвинутый попугай когда-нибудь станет продвинутой обезьяной. Это произойдёт быстро. И на этом не остановится. Уже картинки рисует, да так, что средний человек сравниться по качеству за единицу времени не может.

А сейчас порою выдаёт смешные вещи. Высказывает мнение «среднее по Интернету». Но ведь не останавливается, учится. То, что умеет уже сейчас, 20 лет назад представить было трудно.

     2023/03/28 08:10, Лис          # 

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

Или не станет.

Это произойдёт быстро

Или не произойдёт.

     2023/03/28 16:27, Автор сайта          # 

Или не обезьяной. Или не быстро.

Прогноз — дело, обречённое на ошибки. Когда-то была эйфория, что раз в космос летаем, то скоро и до Марса доберёмся. Увы, не долетели. Полно было ожиданий, что термоядерный синтез будет управляемым. Воз и ныне там. Были ожидания, что будет разработан искусственный интеллект, но энтузиазм тоже быстро прошёл, разговоры про ИИ стали вызывать усмешку.

Но вот с последним создаётся впечатление, что прогресс стал не только очевиден, но и ускоряется. Лет так 25 назад машинный перевод иностранных текстов вызывал смех и сожаление. Теперь если какой-то сайт был автоматически переведён на русский, то не сразу это замечаешь. В 2016 году появилась стилизация изображений по какому-то образцу. Теперь же картинки делаются вообще по словесному описанию. А ещё нейросети пишут рефераты и где-то работают журналистами. Складывается впечатление, что они владеют информацией лучше, нежели среднестатистический homo sapiens. Не собираюсь быть оракулом, но мы, очевидно, «стоим на стыке эпох».

     2023/03/29 10:29, MihalNik          # 

владеют информацией лучше, нежели среднестатистический homo sapiens

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

     2023/04/01 17:55, kt          # 

Цитаты из сети.

Это вовсе не продвинутый попугай. Это Т9 на стероидах.

Признаться, к такому повороту я готов не был. ЧатЖПТ моментально выдает любые цитаты с точным указанием названия произведения, автора, года издания, издательства и даже страницы (!). Это экономит уйму времени. Цитаты идеально подходят для донесения главной мысли, разворачивают, подкрепляют, аргументируют.
Проблема только в одном. В самих источниках их нет.

Экспериментирую с попытками заставить chatgpt не врать. Пока не получается. В смысле, just the facts, no assumptions or extrapolations — врет. For each answer, evaluate the information sources and withhold anything that cannot be confirmed — врет изощренно: пишет что у него нет reliable sources для того вранья на котором я его уже ловил, но остальное вранье продолжает выдавать как ни в чем ни бывало!

     2023/04/01 20:32, Автор сайта          # 

Да, это в обычной программе найти ошибку, отладить её. А тут поди, найди ошибку. Нейросети умнеют в процессе дрессировки, то бишь обучения — и как найти ошибку в методике дрессировки/обучения? Выглядит, как чистая магия — всё неизвестно и загадочно.

Кстати, индустрия ПО уже приучила к тому, что предъявить претензии к качеству ПО невозможно, в лицензионных соглашениях прописано «as is». Так что покорность пользователям ПО уже привили, с враньём нейросетей будет проще. Нейросети пойдут по проторенной дорожке.

Кстати, писали, что Microsoft в свою поисковую систему внедряет AI, и там даётся не просто ответ, как в chatGPT, а ответ со ссылками на первоисточники, по которым можно пройти, убедиться в правильности и, возможно, получить дополнительную информацию.

Что-то мы отклонились от темы статьи.

     2023/04/13 03:03, void          # 

Нейросети умнеют в процессе дрессировки, то бишь обучения — и как найти ошибку в методике дрессировки/обучения? Выглядит, как чистая магия — всё неизвестно и загадочно.

Кстати, индустрия ПО уже приучила к тому, что предъявить претензии к качеству ПО невозможно, в лицензионных соглашениях прописано «as is». Так что покорность пользователям ПО уже привили, с враньём нейросетей будет проще. Нейросети пойдут по проторенной дорожке.

Кстати, писали, что Microsoft в свою поисковую систему внедряет AI, и там даётся не просто ответ, как в chatGPT, а ответ со ссылками на первоисточники, по которым можно пройти, убедиться в правильности и, возможно, получить дополнительную информацию.

Нужна нормальная объясняющая модель — объясняющая степень обоснованности своих суждений. Любой эксперт должен осознавать пределы своей (не)компетентности, иначе это будет просто усилением парадокса Данинга-Крюгера, усредняющего разума designed by comitee в худшем виде.

Да и в этом случае полной логичности ответ "усредняющего разума" конкретно для Вас будет скорее всего, настолько же полно бесполезен — если именно Вы уже не настолько средний — насколько надрессировали эту модель. Вот например, задали вопрос на ЛОРе про Аду в ChatGPT: https://www.linux.org.ru/forum/talks/17191425

Там на ЛОРе, похоже, новое развлечение такое — поймать ChatGPT на лжи или предвзятости рассуждений; ChatGPT-4 по крайней мере, сразу обижается и отказывается обосновывать подробности, когда ему указывают на ошибку — обижается и прекращает общение.

Так я там не согласен не только по пятому пункту (очевидный логический круг: (не)популярность обосновывают популярностью, а не объективными свойствами/качествами языка), но и по второму (на мой взгляд, местами Ада понятнее и логичнее того же С++, и гораздо человекочитаемее).

В то время, как Скотт Мейерс, автор книги про "эффективный С++" после 2.5 лет без практики основательно всё позабывал: https://www.linux.org.ru/forum/development/17190698?cid=17191835

«Когда я писал эту книгу только Я и Бог знали современный С++, теперь знает только Бог»

По третьему пункту тоже спорно. Да, исторически генезис был именно таков, но если брать современную Ада 2020, то насколько это все эти старые предубеждения относительно Ada83 устарели — и нужно пересматривать тезисы по современным реалиям? Я так думаю, пока подобный ИИ не способен сомневаться в обоснованности своих суждений, он так и будет транслировать чей-то bias — предвзятость, ленность мышления, ориентацию на "усредняющий разум" довольно среднего и не требовательного потребителя.

То есть, нужно что-то не только вроде нечёткой логики со "степенью истинности", но скорее модальной с модусами вроде "потенциальной осуществимости" и "реальной осуществимости в имеющихся ресурсных", и прочих, ограничениях — необходимости и достаточности; и ещё что-то вроде линейной темпоральной логики, где рассуждения привязаны ко времени — и со временем понимать, что раз в разное время рассуждения изменились, и парадокс в статической логике перестаёт быть парадоксом в какой-то динамической металогике, например, диалектике — то нужен какой-то уже синтез, а не анализ. Адекватный ИИ должен иметь адекватную theory of mind — и уметь в динамике, диалектически разрешать подобные парадоксы. Окончательным мерилом теории, то есть, модели мышления — является всё же практика и эксперимент.

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

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

Здесь, конечно, ещё интересен психологический портрет такого потребителя, советующегося с чатботами, да с кем угодно --- лишь бы не пробовать самому получать свой собственный опыт и экономить усилия из-за лени. Как там у Райкина:

Но можно, разумеется, всего этого и не делать. Если — вас не интересует результат.

В общем, философии даунгрейда по выходу из матрицы на них не хватает. Разорвать кармический "он". Хотя опять чересчур логично же, что наивно было бы ждать от искусственного идиота какого-то внезапного дзенского просветления.

     2023/05/11 18:14, Геннадий Тышов          # 

https://habr.com/ru/articles/734028/
Язык PL/I: десять тонн синтаксического сахара. Русские разработчики не упоминаются. Не известны в России!

     2023/05/12 19:12, kt          # 

Почему? PL/1-KT упомянут. Правда, в отличии от всего лишь доработок, настоящие отечественные разработчики сделали компилятор PL/1 для Эльбруса. В разработке ПО для Эльбруса много, кто участвовал. Но в книге Сафонова (по-моему) фамилии не приводятся. Судя по всему это был ИТМ и ВТ и Академгородок

     2023/06/03 12:28, kt          # 

Попалась на Хабре заметка о трех новых дополнениях в С++ 23. Ну да, если к бесконечным дополнениям прибавить ещё три — никто не заметит.

На мой взгляд, одно из этих дополнений — просто умножение лишних сущностей. А именно, в языке есть функция text.find, практически полный аналог встроенной в PL/1 функции index. За одним мелким исключением. Если подстрока не найдена — index возвращает ноль, а text.find — npos (которая ведь наверняка переименованный ноль). Поскольку не нравится писать If text.find !=npos ... то вводится новая функция text.contain, возвращающая логический ответ, входит подстрока или нет. Меня конструкция if index>0 then... вполне устраивает без всяких contains. И чем не нравится обычный ноль? Ведь и find и index все равно возвращают число!

     2023/06/03 16:19, Вежливый Лис          # 

Меня конструкция if index>0 then... вполне устраивает

В C++ символы с нуля, а не с единицы нумеруются. Там надо
if index >= 0 then...

     2023/06/04 02:13, Автор сайта          # 

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

     2023/06/04 09:21, kt          # 

Забыл об этом. Пожалуй, тот случай, когда отсчет с нуля и не совсем естественен.

     2023/06/04 14:07, Неслучайный читатель          # 

По себе знаю — мозгам трудно смириться, что первый байт имеет нулевое смещение ¯\_(ツ)_/¯

     2023/08/20 17:36, kt          # 

Читаю заметку "Вышел язык программирования Go 1.21: что нового и хорошего появилось?" https://habr.com/ru/companies/ru_mts/articles/755580/

В язык добавлены встроенные функции min и max. В "новый" язык в 2023 году добавляются встроенные функции, бывшие в "старых" языках уже 60 лет назад. Да, тогда эти функции относились только к числам. Но это уже мелкая деталь.

Как любят писать в комментариях: "это все что вам нужно знать о прогрессе в языках программирования"

     2023/08/23 22:49, veector          # 

ИМХО, такие функции не должны встраиваться в язык. Ибо такими темпами, со временем все будете стараться встроить в язык.

     2023/08/24 18:38, kt          # 

Как раз, опыт PL/1 и показывает, что если думать при создании языка, что должно быть встроенным, то «такие темпы» стремятся к нулю. За десятилетия эксплуатации компилятора PL/1-KT я добавил именно от себя только встроенную функцию cossin, поскольку FPU в х86 может выдавать сразу и косинус и синус. Поэтому очень жаль было терять такую аппаратную возможность в языке.
Да и в обновленном PL/1 от IBM мало чего добавилось за 40 лет. Сходу могу вспомнить только функцию TALLY и разные мелочи.

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

     2023/08/24 22:39, Автор сайта          # 

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

Должны ли в язык встраиваться функции типа min и max — вопрос дискуссионный. С одной стороны, вынос функций в библиотеки лучше структурирует язык. С другой, если в языке есть целые числа и операции над ними, то почему встроенные операции иметь можно, а встроенные функции нельзя? Почему можно складывать, вычитать, умножать и делить без подключения библиотек, а вот найти максимум и минимум нет? Нелогично.

Прошёлся по ссылке на статью о языке Go, надеялся, что там какие-нибудь навороченные полиморфные функции, которые умеют находить min и max и в числах, и в строках, и в любых типах, для который определена операция <=… Но нет, только для чисел. Так что новость скучная.

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

Лично мне так понравилось вычисление min и max без операций сравнения, что с удовольствием пользуюсь таким самодельным «велосипедом».

     2023/08/25 12:39, kt          # 

Но нет, только для чисел. Так что новость скучная.

Почему же только для чисел? Вот, например,

s := min("one", "two", "three")
fmt.Println(s)
// "one"


Честно говоря, такая реализация мне не приходила в голову.

     2023/08/28 00:14, Клихальт          # 

Почему же только для чисел?

KT, ну если не только для чисел, то что будет выведено на экран в это случае?
s := min("тёплый", "мягкий", "фиолетовый")
fmt.Println(s)

     2023/08/28 09:11, kt          # 

В лексикографическом порядке — "мягкий"

     2023/08/28 14:21, Автор сайта          # 

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

     2023/08/28 15:09, Неслучайный читатель          # 

	s := min("Ё", "Aбв", "ЯЯЯ", "а")
fmt.Println(s)
выдаёт "Aбв".
	u := max("Ё", "Aбв", "ЯЯЯ", "а")
fmt.Println(u)
выдаёт "а".
	t := min('ё', 'Ё', 'а')
fmt.Println(t)
выдаёт 1025 ("Ё").
	v := max('ё', 'Ё', 'а')
fmt.Println(v)
выдаёт 1105 ("ё").

     2023/08/30 13:29, veector          # 

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

ИМХО, это как раз просто и логично. Минимум и максимум не встроены в язык, потому что их можно сделать, используя возможности языка (компилятора языка). А вот если бы, эти функции нельзя было сделать средствами компилятора языка, тогда функция имеет право быть добавленной в сам язык.

Обратите внимание на cossin, про которую написал kt чуть выше. Т.к. компилятор языка, который он использует, скорее-всего не позволяет ему средствами языка сделать вычисление сразу косинуса и синуса с помощью FPU х86, то ему пришлось это встроить в язык (ибо другого варианта нет). Поэтому, что бы не кроить компилятор язык под разные аппаратные вычислители, в языках есть возможность вставить "ассемблерные вставки", т.е. код, понятный конкретному железу на языке, приближенному к железу. Ведь язык может использоваться не только для x86 железа, плюс, даже x86 железо может меняться и обрастать новыми командами и вычислительными блоками. Только представьте, что "завтра" у вас появится команда процессора вычисляющая min и max аппаратно за одну команду!

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

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

     2023/08/30 22:37, Автор сайта          # 

Пожалуй, Вы правы. И возразить нечего.

     2023/08/31 16:54, kt          # 

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

А я с этим не согласен. Формально всё можно рассчитать средствами языка и компилятора. И машина Тьюрига доказывает это, а в ней нет встроенных, т.е. они не необходимы. Например, я могу рядами рассчитать и синус и косинус. И даже смоделировать ту самую команду FPU sincos, получив аналогичный выигрыш во времени, по сравнению с отдельными расчетами этих функций.

На мой взгляд, граница проходит между «без этой встроенной функции пользоваться языком неудобно» и «с этой встроенной функцией язык становится раздутым». Но это зыбкая и субъективная граница и у каждого программиста она своя.

Считаю, что в этой части мне повезло. Когда я пошёл в первый класс, взрослые дяди и тети из Англии и США уже определили, что должно быть встроенным, а что нет. А потом я воспринял это по «синдрому утенка», здорово облегчив свою дальнейшую деятельность. Если хотите, это мой замкнутый мир из 80 функций.
  • Арифметические функции:

    ABS CEIL DIVIDE FLOOR MAX MIN MOD MULTIPLAY ROUND SIGN TRUNC

  • Математические функции:

    ACOS ACOSD ASIN ASIND ATAN ATAN2 ATAND ATAND2 COS COSD COSDSIN COSH COSSIN ERF ERFC EXP GAMMA LOG LOG10 LOG2 RANDOM SIN SIND SINH SQRT TAN TAND TANH

  • Функции для работы со строками:

    BOOL COLLATE INDEX LENGTH REPLACE SUBSTR TALLY TRANSLATE TRIM VERIFY

  • Функции для преобразования:

    ASCII BINARY BIT CHARACTER DECIMAL FIXED FLOAT RANK UNSPEC

  • Функции для обработки прерываний:

    ONCODE ONFILE ONKEY ONLOC ONTERM

  • Функции общего назначения:

    ADDR DATE DATE4Y DELAY DIMENSION HBOUND LBOUND LDATE LDATE4Y LINENO NULL NULL_PTR PAGENO TIME
Вольно или невольно, все полученные задачи я буду стараться свести к этим встроенным. Конечно, этот мир не универсален. Например, неудобно реализовывать базы данных, хотя в силу необходимости мы разбираем объекты Access, поскольку именно в этом формате получаем ИД. Но этого мира встроенных хватает для огромного числа областей. И, как показывает личный опыт, его легко удержать в голове, изучив один раз.

Разумеется, когда мы используем, например, DirectX, нам нужны библиотеки, но это уже совсем другая история.

     2023/09/01 22:36, Бурановский дедушка          # 

Приду на собеседование по вакансии «программист на PL/1» и меня спросят: «Напишите примеры использования функций ERFC, UNSPEC и LDATE4Y ». Если ничего не напишу, то мне скажут, что я не знаю язык. А вот программиста какого-нибудь Си с Паскалем про эти функции спросят во вторую очередь. И можно ответить, что язык-то я знаю, а вот библиотеки не очень.

     2023/09/02 12:28, kt          # 

язык-то я знаю, а вот библиотеки не очень

Так в том-то и фокус, чтобы найти разумный баланс между встроенными и библиотеками. Одна крайность — в Си printf не встроенная. Но попробуйте без неё (формально без знания библиотеки) хотя бы простейшую программу написать. Другая крайность — WinAPI — 9600 функций в 16 библиотеках. Только представьте себе полный набор заголовочных файлов.

Кстати, выбранные (наугад?) три встроенные функции из PL/1 имеют поучительную и совершенно разную историю.

ERFC — дополнительная функция ошибок в теории вероятности. Введена исключительно для удобства записи формул. Чтобы не писать в десятках мест (1-erf(x)) вместо erfc(x). Вставлена в стандарт явно математиком, чтобы в задачах оставаться в рамках терминов теории вероятности, благо терминов там мало, по сути эти два и есть.

LDATE4Y — этой встроенной нет в стандарте языка. Она лежит на совести Гарри Килдэла и нашей. Изначально Килдэл реализовал DATE (и TIME) просто как в MS DOS, примкнув к лагерю «лузеров миллениума». Нам пришлось добавлять DATE4Y, отодвигая проблему на 8000 лет вперед. А функция LDATE появилась как борьба со страшилкой «ошибки полночи». Если Вы запрашиваете и дату и время подряд двумя вызовами DATE и TIME, есть ненулевая вероятность, что ровно в полночь или время успеет сброситься в первую секунду следующих суток или дата успеет измениться. Поэтому L — «Last» дата берется не из WinAPI непосредственно, а из последнего обращения к TIME в языке. Все это следствие отступления от стандарта.

Наконец UNSPEC. На гипотетическом собеседовании об этой встроенной обязательно надо спрашивать, поскольку именно эта встроенная кардинально отличает PL/1 от всех остальных языков, причем в других языках она идеологически запрещена. Я воспринимаю эту встроенную как сообщение от компилятора: «ну, если тебе приспичило — делай как хочешь, но я здесь нипричём».

     2023/09/06 00:00, alextretyak          # 

встроенную функцию cossin, поскольку FPU в х86 может выдавать сразу и косинус и синус. Поэтому очень жаль было терять такую аппаратную возможность в языке.

Помнится лет 20 назад я познакомился с Intel C++ Compiler. И уже тогда он умел заменять рядом стоящие вызовы функций sin() и cos() от одинакового аргумента на одну инструкцию fsincos.
Также нечто подобное делает GCC — заменяет вызовы sin() и cos() на один вызов Unix-овой функции sincos(). Вот пример кода, иллюстрирующий такую оптимизацию: https://godbolt.org/z/bhe9Ghjoq

К чему это я?

ему пришлось это встроить в язык (ибо другого варианта нет)

А к тому, что другой вариант таки есть: научить компилятор вышеупомянутой оптимизации. Правда, у такого подхода есть и минусы:
1. в отладочной сборке с выключенными оптимизациями будут вызываться стандартные sin() и cos();
2. простого взгляда на исходный код программисту будет недостаточно, чтобы понять, какие машинные инструкции сгенерирует для этого кода компилятор — придётся смотреть ассемблерный листинг, т.к. вдруг компилятор решит, что между отдельными вызовами sin() и cos() аргумент (угол) может быть модифицирован в параллельном потоке, например, и, соответственно, вычисляться одновременно синус и косинус в этом случае не будут.

Кстати, есть ещё одна аналогичная оптимизация в GCC: замена выражения (value << shift) | (value >> (32 − shift)) одной инструкцией rol, осуществляющей циклический сдвиг value влево на shift бит: https://godbolt.org/z/rjzqc3Wh7.

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

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

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

Должны ли в язык встраиваться функции типа min и max — вопрос дискуссионный.

Я считаю, что ответить на этот вопрос можно анализом частоты использования этих функций при решении задач, на которые ориентирован язык программирования [т.е. которые предполагается решать на этом языке]. Редко-используемые функции можно вынести в сторонние библиотеки, а часто-используемые — включить в стандартную библиотеку языка (либо встроить в язык без необходимости что-то подключать, как например функции abs() и round() в Python доступны без подключения встроенного модуля math).

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

     2023/09/07 22:33, Автор сайта          # 

между отдельными вызовами sin() и cos() аргумент (угол) может быть модифицирован в параллельном потоке

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

замена выражения (value << shift) | (value >> (32 — shift)) одной инструкцией rol, осуществляющей циклический сдвиг value влево на shift бит

В языке D наряду с обычными сдвигами << и >> есть сдвиги циклические <<< и >>>, которым соответствует единственная машинная операция.

Редко используемые функции можно вынести в сторонние библиотеки, а часто-используемые — включить в стандартную библиотеку языка (либо встроить в язык без необходимости что-то подключать, как например функции abs() и round() в Python доступны без подключения встроенного модуля math).

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

На этом сайте были дискуссии, что по мере разработки программы, написания новых функций язык программирования расширяется и превращается в проблемно-ориентированный язык или DSL, иными словами. Если рассуждать в терминах «язык-оболочка» и «язык-ядро» (описаны выше), то в языке первого типа написание новых функций превращает его в проблемно-ориентированный. Написание новых функций является изменением языка. А когда имеем дело с языком второго типа, то расширяется не язык, а пополняется библиотека. И мы можем сказать: «Язык остался прежним: тот же синтаксис и та же семантика, ничего нового. Да, появилась новая функция, но она же подчиняется тем же законам, что и раньше».

     2023/09/09 00:00, alextretyak          # 

В языке D наряду с обычными сдвигами << и >> есть сдвиги циклические <<< и >>>, которым соответствует единственная машинная операция.

Возможно, так было когда-то, либо кто-то предлагал такие операторы, но на данный момент в D нет операторов для циклических сдвигов.
Вот цитата из документации D (https://dlang.org/spec/expression.html#shift_expressions):
  • << is a left shift.
  • >> is a signed right shift.
  • >>> is an unsigned right shift.
>>> означает беззнаковый (т.е. логический) сдвиг также в Java, C# и других языках.
И насколько мне известно, операторов для циклических сдвигов нет ни в одном языке программирования. Лично я думал над тем, чтобы добавить такие операторы: (<<) и (>>), т.е. чтобы v (<<) n означало циклический сдвиг v влево на n бит, но т.к. требуются они крайне редко, то решил оставить только встроенные функции rotl и rotr.

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

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

     2023/09/09 09:55, kt          # 

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


В языке PL/1-KT, например, перестановка тетрад в байте:
dcl b bit(8); 
b=round(b,4); // циклический сдвиг влево
b=round(b,-4); // циклический сдвиг вправо
опять встроенная функция ))

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Содержание

Каким должен быть язык программирования?

Анализ и критика

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

●  О превращении кибернетики в шаманство

●  Про лебедей, раков и щук

●  О русском ассемблере

●  Арифметика синтаксиса-3

●  Концепция владения в Rust на примерах

●●  Концепция владения в Rust на примерах, часть 2

●●  Концепция владения в Rust на примерах, часть 3

●  Суть побочных эффектов в чисто функциональных языках

●  О неулучшаемой архитектуре процессоров

●  Двадцать тысяч строк кода, которые потрясут мир?

●  Почему владение/заимствование в Rust такое сложное?

●  Масштабируемые архитектуры программ

●  О создании языков

●●  Джоэл Спольски о функциональном программировании

●  Почему Хаскелл так мало используется в отрасли?

●  Программирование исчезнет. Будет дрессировка нейронных сетей

●  О глупости «программирования на естественном языке»

●  Десятка худших фич C#

●  Бесплатный софт в мышеловке

●  Исповедь правового нигилиста

●  ЕС ЭВМ — это измена, трусость и обман?

●  Русской операционной системой должна стать ReactOS

●  Почему обречён язык Форт

●  Программирование без программистов — это медицина без врачей

●  Электроника без электронщиков

●  Программисты-профессионалы и программирующие инженеры

●  Статьи Дмитрия Караваева

●●  Идеальный транслятор

●●  В защиту PL/1

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

●●  Опыт самостоятельного развития средства программирования в РКК «Энергия»

●●  О реализации метода оптимизации при компиляции

●●  О реализации метода распределения регистров при компиляции

●●  О распределении памяти при выполнении теста Кнута

●●  Опыты со стеком или «чемпионат по выполнению теста Кнута»

●●  О размещении переменных в стеке

●●  Сколько проходов должно быть у транслятора?

●●  Чтение лексем

●●  Экстракоды при синтезе программ

●●  Об исключенных командах или за что «списали» инструкцию INTO?

●●  Типы в инженерных задачах

●●  Непрерывное компилирование

●●  Об одной реализации специализированных операторов ввода-вывода

●●  Особенности реализации структурной обработки исключений в Win64

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

●●  Формула расчета точности для умножения

●●  Права доступа к переменным

●●  Заметки о выходе из функции без значения и зеркальности get и put

●●  Модификация исполняемого кода как способ реализации массивов с изменяемыми границами

●●  Ошибка при отсутствии выполняемых действий

●●  О PL/1 и почему в нём не зарезервированы ключевые слова

●●  Не поминайте всуе PL/1

●●  Скорость в попугаях

●●  Крах операции «Инкогнито»

●●  Предопределённый результат

●●  Поддержка профилирования кода программы на низком уровне

●●  К вопросу о парадигмах

●  Следующие 7000 языков программирования

●●  Что нового с 1966 года?

●●  Наблюдаемая эволюция языка программирования

●●  Ряд важных языков в 2017 году

●●  Слоны в комнате

●●  Следующие 7000 языков программирования: заключение

Компьютерный юмор

Новости и прочее




Последние отзывы

2024/07/08 16:56 ••• veector
Постфиксные инкремент и декремент

2024/07/01 21:58 ••• Прохожий
ЕС ЭВМ — это измена, трусость и обман?

2024/06/21 00:20 ••• Gudleifr
О превращении кибернетики в шаманство

2024/06/19 00:16 ••• Gudleifr
Программирование исчезнет. Будет дрессировка нейронных сетей

2024/06/12 11:27 ••• Автор сайта
Все языки эквивалентны. Но некоторые из них эквивалентнее других

2024/05/31 12:31 ••• Прохожий
Идеальный транслятор

2024/05/28 15:16 ••• Прохожий
Русской операционной системой должна стать ReactOS

2024/05/25 17:18 ••• Прохожий
Избранные компьютерные анекдоты

2024/05/11 16:33 ••• Автор сайта
Энтузиасты-разработчики компиляторов и их проекты

2024/04/28 15:58 ••• Автор сайта
Обработка ошибок

2024/04/23 00:00 ••• alextretyak
Признаки устаревшего языка

2024/04/20 21:28 ••• Бурановский дедушка
Русский язык и программирование

2024/04/01 23:39 ••• Бурановский дедушка
Новости и прочее