Как стать автором
Обновить

Комментарии 51

ни разу — перемножать массивы.

Но в целом, это типичная ситуация: возможность используется не часто или вообще не используется


numpy, например. Достаточно востребованная операция.

Точно. Векторизация операций на массивах в таких ранних языках – пример изрядной дальновидности.

Интересно, а как Ваш компилятор воспримет
решённые примеры по PL/I с ресурса rosettacode.org (наверное, в каких то моментах, придётся дорабатывать)

P.S. https://pl1.su/ — Язык программирования номер один :)

Интересный тред получился «Не поминайте всуе PL/1» на площадке http://compiler.su (на сайте ещё есть несколько тредов относящихся к PL/1)

https://habr.com/ru/post/588987/comments/

вот эта программа как раз и упоминается на одной из веток Розетты - на ветке теста Кнута.

Работал несколько ко лет на pl/1. Из всех книг легче всего освоить было по книге Пярнпуу. Было на ивц. Асса переходных книг толщиной с краткий курс истории КПСС то есть кирпич. Но у Пярнпуу было как потом возн кла серия для чайников. Доступно, по теме и с практической направленностью. Моменты которые были не освещены в книге смотрел уже в документации по ес эвм. Потом после того как машина ну переплавили на золото нашел на одном из дисков компилятор pl/1 но так уже ничего на нем не написал хотя ностальгические настроения возникли. Кстати о названии тол ко сейчас обратил внимание ibm/360 pl/1 os/2 у ibm своеобразный подход к выбору названий.

AS/400, PS/1, PS/2, System/36, System/38 и так далее и тому подобное.

И еще важный момент. Я сторонник использования родного языка в программировании.

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

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

Рискну предположить что мир автора заканчивается ровно на границе рф.

Хорошо, если так. Скорее всего он заканчивается на проходной, отделющий его отдел от соседних.

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

  1. Фантастической стоимости всего, связанного с Роскосмосом.

  2. Чудовищно низких зарплат у большинства работников.

А всё просто: если объявить, что у нас тут космос, всё супер-пупер уникальное, сделано под заказ и, условно говоря, вытачивать каждый болт на отдельном, созданом конкретно для этого болта станке и писать программы для каждого блока на отдельном, разработанном специально для этого блока, языке программирования… ооо… тут можно освоить любые средства́ и ещё мало будет.

Прям такой заповедник позднего СССР живой.

А ты высокомерно стремишься общаться (в широком понимании) на кириллице во имя не пойми чего.

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

Ну почитайте же Паркинсона, он прекрасно всё описал.

Сначала немного напрягла фраза "И не в какое-нибудь «дежавю» (такие образы этой книги давно есть в сети), а в настоящий .DOCX.", хотел было уточнить -- почему именно docx, почему не fb2, например?

Ткнул в ссылку для скачивания, а там хорошо свёрстанный pdf. Отлично!

Мне непонятно, почему не (La)TeX. Это же самое уместное средство для таких применений.
И pdf отлично свёрстанный со всеми плюшками, да и html…

В данном случае самое уместное средство — Markdown на гитхабе, возможно с автоконвертацией в статический сайт с хостингом на GitHub Pages.

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

Я в своё время La(TeX) пытался освоить, но на сегодняшний день не стал бы пытаться его использовать без крайней необходимости.

\documentclass{article}\usepackage{useful-settings}
\begin{document}

\chapter{О проблемах Латеха}

Скажите пожалуйста, какие трудности возникают при \emph{освоении} Латеха и какие при его \emph{использовании}?

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

\begin{quotation}
Спасибо!
\end{quotation}

\end{document}

Очень простые — его надо осваивать.Ваш пример, который должен иллюстрировать как всё просто, иллюстрирует и это.

Если говорить про меня — у меня жёсткий недостаток времени и я бы точно не стал тратить его на освоение LaTeX ради вёрстки одной книги.

P.S. хотя было бы любопытно, конечно, взглянуть — как бы выглядела в LaTeX'е страница 6, например.

P.P.S. у меня, вероятно, очень устаревшие сведения, но помнится раньше надо было ставить какие-то неочевидные пакеты, подключать что-то в LaTeX для вёрстки в формат А4, в общем, всё было не так просто. Сейчас, вероятно, с этим гораздо проще.

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

Про недостаток времени вы правы. В такой ситуации невозможно освоить и Word, который после 2003 года стал очень сложным.

Возможно, но я вот вижу свёрстанную в Word книгу и много рассуждений о том, как было бы просто сверстать её в LaTeX.

Я снова прошу вас показать — как бы выглядела свёрстанная в LaTeX странца 6 из приведённой выше книги? Ведь это же так просто!

Если у меня появится свободное время, я буду готов попробовать.

В общем-то несложно, да.

https://www.overleaf.com/read/ttbdchmgbrcr

На самом деле, никто таким не занимается. В издательствах служебные страницы делают отдельно (тоже не в ворде).

Насчет хорошо сверстанного pdf вы погорячились. Но я согласен, что его большое преимущество состоит в том, что он есть.

Спасибо за иллюстрацию.
Замечательный пример использования LaTeX. Занёс в закладки.

Замечательный пример использования LaTeX

не по назначению.

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

Назначение Латеха — вёрстка и издание книг с хорошим научным аппаратом. Раньше бумажных, а теперь электронных.

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

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

Кстати, в Латехе можно посчитать выходные сведения: количество авторских листов, издательских листов и всё прочее.

У меня вопрос: лично вы много книг сделали в латехе? И не в латехе?

Очень много. Очень. Самый удобный инструмент.

А не в Латехе (то есть в индизайне) очень мало.

Он удобный, я же не спорю. Смотря для чего. Например, когда верстали вот это http://www.encyclopedia.ru/cat/books/book/3307/, с гладким текстом, делали в латехе. А когда на основе той же базы делали это https://www.labirint.ru/books/152524/, это https://www.labirint.ru/books/152525/ и еще несколько штук не помню чего, с рисунками в оборку в узких колонках и т.п., сделали вывод не в латех, а в индизайн. Выходные данные, если мне память не изменяет, в том издательстве делали в индизайне всегда.

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

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

Всё это выглядит как-то чрезмерно. Неужели число страниц в библиографической карточке записывали вручную? И код ББК в двух местах указывали вручную?

Простите, вы не А.Ю.Ф., часом?

Это инициалы, да? У меня другие.

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

Получается, что одну (!) книгу сначала делают в двух (!) программах, разные страницы в разных программах. Потом её каким-то образом соединяют (!) в один макет.

Acrobat или psutils.

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

Что стирают? Где стирают? В случае этих словарей, кстати, главную ценность представляла исходная словарная база. Макет-то в pdf на фиг кому нужен, его же просто так напечатать нельзя, засудят, а информацию из него с разумными затратами не добыть. Грамота.ру, между прочим, некоторые из этих словарей использует - очевидно, легально.

Всё это выглядит как-то чрезмерно. Неужели число страниц в библиографической карточке записывали вручную? И код ББК в двух местах указывали вручную?

Сверставши 800-2000 полос, не переломились ББК вбить вручную. Тем более, что там еще надо было номер типографского заказа вбивать.

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

Кстати, как сделать рисунок в оборку, например, в верхнем внешнем углу? Есть такие средства?

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

Жесть какая )) А зачем оно нужно когда уже давно есть Markdown?

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

А вот пример семантической вёрстки на Латехе.

\begin{habr}
\glava{Пример семантической вёрстки}

Скажите пожалуйста, какие трудности возникают при освоении \LaTeX{}
и какие \glavnoe{при его использовании}? Прошу вас, назовите
для примера хотя бы пять. Оставлю для этих причин место в списке.

\begin{spisok}
\punkt\punkt\punkt\punkt\punkt
\end{spisok}

\spasibo{Спасибо!}
\end{habr}

 Но даже с учетом всех этих обстоятельств, общий тираж изданий книги Фролова и Олюнина велик, он превысил 300 000!

Я держу в руках книгу Р.Д. Джордейна "СПРАВОЧНИК программиста персональных компьютеров типа IBM PS, XT и AT" (М.: Финансы и статистика, 1992). Читаю: "Доп. тираж 150 000 экз.". И это только дополнительный тираж.

Потому, что еще Л.Ф. Штернберг (как знаток языка) утверждал, что если создать язык, отличающийся от PL/1 только тем, что из него убраны некоторые возможности, получится язык лучший, чем PL/1.

Гениально! Убрать, чтобы улучшить. Жалко, что этому совету никто не следует. Ну, или, почти, никто...

И не в какое-нибудь «дежавю» (такие образы этой книги давно есть в сети), а в настоящий .DOCX

А почему не \TeX?

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

Хотя существующие возможности это позволяют.

Интересно.

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

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

Как ваш прозрачно-переводчик решит эту проблему? Особенно когда особый термин — внутренний для предприятия?

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

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

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

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

Но во времена PL/I говорить про трейты, дженерики и мономорфизацию было бы преждевременно, потому что эти идеи только-только зарождались, а не были мейнстримом.

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

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

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

Во времена fortran и pl/i такого даже близко не было, так что для выразительности приходилось всё тащить в обязательный рантайм.

Ладно. В недалёком будущем придётся вернуться к этому. И тогда я опрошу Вас немного подробнее. Не возражаете?

NP, хотя "времена фортрана" я знаю поверхностно.

>Но во времена PL/I говорить про трейты, дженерики и мономорфизацию было бы преждевременно,

imho, как язык PL/1 производил типа унылое впечатление с момента его появления (как и вся OS/360), в отличии например от идей заложенных в algol-68, или Ada, в историческом плане PL/1 все таки связан с UK (IBM Hursley 1966-68), довольно интересно сравнение PL/1 vs Algol-68, например в статье примерно того времени S.H. Valentine, "Comparative notes on Algol-68 and PL/1", (Staffordshire University UK), легко найти при желании в сети, это к вопросу о "преждевременности"

ps

Multics PL/I компилятор (очень грамотная работа с участием GE) был написан чуть позже Hursley Lab, хотя подмножества PL/1 использовались в US примерно с середины 60x в том числе в Bell и MIT

imho, как язык PL/1 производил типа унылое впечатление с момента его появления (как и вся OS/360), в отличии например от идей заложенных в algol-68, или Ada,

Угу, только что еще в то время было доступно, кроме OS/360 и чуть позже OS/370 и VM/SP, где кроме ассемблера (кто-нибудь еще помнит правила использования R13, R14 и R15 для вызова/возврата из процедур?), фортрана-60 (с массивами фиксированной на этапе компиляции длины и идиотским if) и PL-1, ничего больше и не было (для научно-технических расчетов).

Большое спасибо! Если это не разглашение гос-тайны, а где именно могут применяться такие старые языки и для чего именно они на МКС? Интересно.

Для баллистико-навигационного отображения экипажу полетной обстановки. Правда, это не входит в в систему управления, но нужно экипажу в повседневной деятельности.

Ну, а по поводу старого языка - а что в этой задаче нужно нового? Монады с ленивыми вычислениями? Так оно здесь не нужно. И перегрузка операторов не нужна.

PL1 программировал но как то впечатления не произвел, так - всего лишь фортран для бухгалтерских задач. А вот JCL запомнился. Без него с ЛПМ было работать затруднительно.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории