Комментарии 36
> для Манхэттенского проекта покодила с Джоном фон Нейманом, результатом чего стало появление американского ядерного оружия
небольшое дополнение - участие Грейс Хоппер было коротким эпизодом, по просьбе фон Неймана она решала уравнение в частных производных, типа несколько месяцев работы, в общем без знания для чего, фон Нейман был консультантом по всем сложным вопросам, общался со всеми, но непосредственно в работе не участвовал, вероятно наибольший вклад в организацию вычислений внес Ричард Фейнман, хотя прямо в его обязанности это не входило, ниже фон Нейман, Фейнман, Станислав Улам (1944)
программировался Mark I довольно своеобразно, см. ниже
1) с одной стороны - ну да, вроде и всего ничего, но наверно "порешать уравнения" фон Нейман мог попросить и студента, однако почему-то не попросил ?
2) действительно - все наглядно и понятно, зачем еще какие-то промежуточные языки программирования ?
(которые только зря место занимают, а уж про "компиляцию С++" https://xkcd.ru/303/ кто только не шутил! :D )
/сркзм/
> но наверно "порешать уравнения" фон Нейман мог попросить и студента, однако почему-то не попросил
не будем фантазировать, про Mark I не только студенты, но и профессора не слышали вообще в то время, да и доступ в Harvard не у каждого был :)
интересно, что примерно в то же время в Германии вполне себе аналог был в разработке (Zuse Z4), после войны он работал в ETH Zurich, первый язык высокого уровня Plankalkül был в виде проекта для Z4 уже в 1948, на десяток лет опережая cobol и fortran
Языком высокого уровня Планкалькуль сложно назвать. Это очень громоздкий ассемблер скорее.
> Это очень громоздкий ассемблер скорее.
Пожалуйста приведите аргументы. Knuth в своей статье “The Early Development of Programming Languages” (Knuth, Pardo 1976) относит Plankalkül к языкам высокого уровня, статья хорошо известна, его аргументы более-менее понятны, давайте обсудим Ваши.
ps
нотация необычная конечно, пример сравнения можно посмотреть например
https://craftofcoding.wordpress.com/2021/06/23/plankalkul-the-first-language-ii/
Да чё уж, вот сразу книга, на которую вы ссылаетесь http://www.club.cc.cmu.edu/~ajo/disseminate/STAN-CS-76-562_EarlyDevelPgmgLang_Aug76.pdf
Мой аргумент простой: действующее определение языка программирования высокого уровня по ГОСТ 19781-90: язык программирования, понятия и структура которого удобны для восприятия человеком.
Планкалькуль для восприятия – ад. Мнение Кнута – понятно, его восторг – тоже, но это всё же не язык высокого уровня.
ну понятно, статья доступна много где, у меня к примеру это один из многих файлов, примерно представляю как писался ГОСТ 19781-90, это не аргумент, не знаю где Вы увидели эмоции в статье Кнута, советую прочитать более внимательно, и подумать самому типа без ГОСТ
это не аргумент
Это определение было. В начале спора надо устаканиться с определениями, я вам это определение дал, и я с ним согласен.
Да и по другим параметрам он не язык высокого уровня. Трёхадресный ассемблер с индексной адресацией, причём для каждого аргумента и для результата – свои фреймы; при этом не допускающий ни глобальных переменных, ни рекурсии – сорри, может, в 1977 это могло считаться языком высокого уровня.
Сегодня это больше напоминает нечитаемый IR в процессе работы какого-нибудь компилятора, это причём ещё в плоском синтаксисе.
В 2Д синтаксисе Планкалькуль – просто каша, двумерные таблицы программ Ады Лавлейс и то лучше читаются, хотя там тоже по сути трёхадресный ассемблер, даром что на 100+ лет старше.
> при этом не допускающий ни глобальных переменных, ни рекурсии – сорри, может, в 1977 это могло считаться языком высокого уровня...
заметим в ГОСТ 19781-90, не упоминаются ни глобальные переменные, ни рекурсии, вообще про языки высокого уровня примерно 8 слов + два предлога, довольно убогий документ, но есть шедевры типа -
"адрес в пространстве памяти = элемент множества порций данных, являющегося областью определения функции адресации ",
в соответствии с обычаями habr, минус в карму это Ваш последний аргумент, без разницы конечно, приятно быть вместе с Кнутом, против ГОСТ 19781-90, :)
на самом деле мне когда-то давно тоже пришлось поучаствовать в разработке стандартов на sw, причем более важных чем ЕСПД
приятно быть вместе с Кнутом
Это ваш единственный аргумент, других у вас и не было.
Даже ребята, которые частично реализовали это академическое упражнение на Яве, по пути навставляв в ужасающий синтаксис костылей чтобы хоть как-то обойти противоречия или просто ошибки в работах Цузе, и те в конце говорят «However, claims that the Plankalku ̈l was a complete high-level programming language are questionable.»
И ребята эти правы.
Простите, на этом всё. С верованиями спорить бесполезно.
> Даже ребята, которые частично реализовали это академическое упражнение на Яве
вполне понимаю этих ребят и их точку зрения, но они выражаются корректно и только на основе собственного опыта, на ГОСТ 19781-90 не ссылаются :)
вот Вы пишете в своих комментариях "их роутеров .. даже было расковырял", это нормально, но с уровнем примерно понятно, при этом пытаетесь учить, мне к примеру долгое время приходилось делать это самое embedded sw причем для routers и пр. уровня производительности какие Вы вероятно никогда не увидите в жизни,
про мои верования - это 50+ лет в программировании, из них 30+ работы в us, начиная с digital, все время сети и real time
Ну читабельным, в отличии от COBOL, он не был. Оригинальная нотация была вообще двухмерной.
Мне на COBOL пришлось около года программировать, не считая редкие подработки в поддержке, которые случаются до сих пор. Для своих целей он вполне удобен. По крайней мере формировать документы из него для печати на АЦПУ было точно удобней, чем на FORTRAN, PL/I или даже C.
> читабельным, в отличии от COBOL, он не был. Оригинальная нотация была вообще двухмерной.
конечно, das Museumsstück, таки 1948 год
> Мне на COBOL пришлось около года программировать
на Fortran (БЭСМ-6) тоже пришлось в свое время, но COBOL вероятно не смог бы совсем, это личное конечно, при всем уважении типа по Dijkstra -
“The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.”
Ну к моменту освоения COBOL, на FORTRAN мне уже приходилось программировать. COBOL после него был как раз хорош. Структурное программирование, возможность вообще не пользоваться GOTO, развитые структуры данных, встроенный генератор отчетов, простой и прозрачный интерфейс к внешним данных, начиная от ленты и заканчивая СУБД (тогда это была IDMS) - всего этого в FORTRAN IBM/370 тогда еще не было.
Да ну ладно. PL/I включает все возможности Кобола, только в гораздо более удобном для восприятия виде.
Имеет все возможности для работы с магнитными лентами, ISAM методом доступа и встроенный генератор отчетов?
Может я что-то пропустил, но в проектах на PL/I с лентами мне приходилось работать переходя на ассемблер. Родной поддержки ISAM я в PL/I вообще не встречал - тоже ходи через ассемблер. А генераторы отчетов для него я впервые увидел только в начале 90-х. Да и то, так как они прикручивались сбоку, то по удобству явно уступали COBOL. В итоге отчеты нередко предпочитали формировать через файлы сформированные PL/I при помощи того же COBOL. Декларативное описание отчета в COBOL оказывалось существенно дешевле в поддержке, чем процедурное в PL/I
Что касается лент и ISAM, то их поддержка была в компиляторе PL/I того времени. Генератора отчётов, действительно, не было. Но я не работал с генератором отчётов и не очень понимаю, чем в практическом смысле он отличается от присваивания структуры BY NAME.
Что касается лент и ISAM, то их поддержка была в компиляторе PL/I того времени.
https://www.ibm.com/docs/en/SSQ2R2_14.0.0/com.ibm.ent.pl1.zos.doc/pg.pdf
"Enterprise PL/I provides no support for ISAM datasets"
Поддержка лент была рудиментарной. Смонтировать и размонтировать ленту никак, а ведь файлы могли быть многотомными. Читать в обратном направлении - тоже. С блоками неизвестного размера работать не умел. С метками лент или несколькими файлами на одной ленте - тоже.
При том, что из COBOL быстро перемотать ленту к нужному файлу проблем не представляло. И вывести на консоль просьбу установить ленту и указать, на какой накопитель ее оператор поставил - тоже. И проверить метку, чтобы убедиться, что оператор не накосячил - само собой.
"Enterprise PL/I provides no support for ISAM datasets"
Это новый компилятор для zSeries, в нём поддержки ISAM уже нет, так как вопрос потерял актуальность. Вы читаете как раз список его отличий от старого компилятора PL/I for MVS & VM.
Монтирование и управление метками лент для программ на PL/I выполнялось средствами JCL (или CP/CMS). Читать в обратном направлении и работать с блоками неизвестного размера PL/I умел.
Это новый компилятор для zSeries
Ваш пруф?
средствами JCL
Спасибо, не надо. Средства JCL во-первых, статичны, во-вторых, почти ничего из перечисленного мной выше не поддерживают.
Например, как Вы на JCL собрались описывать несколько файлов на ленте, если Вы даже не знаете, сколько файлов девочка на СПД туда наколотила?
CP/CMS
Мы вообще о чем и о каких временах? Какая на хрен СВМ на EC-1033? Ее даже на ЕС-1061 не поднимешь. Только начиная с ЕС-1046. К моменту появления СВМ я уже свалил на ПК с NEC V20 и вовсю писал на С.
Ваш пруф?
https://www.ibm.com/docs/en/developer-for-zos/14.0?topic=compiler-understanding-limitations-new
По-моему, даже у Фролова и Олюнина описывалась работа с ISAM в PL/I. Я лично от этого был далёк, поскольку работал преимущественно в СВМ.
Если не ошибаюсь, компилятор PL/I(O) штатными средствами поддерживал все методы доступа того времени, кроме VTAM.
Мы вообще о чем и о каких временах?
Ну вы не уточняли, о каких временах.
Какая на хрен СВМ на EC-1033? Ее даже на ЕС-1061 не поднимешь.
Я лично много работал в СВМ на ЕС-1061. Она поддерживала машины, начиная с Ряда-2. Хотя на ЕС-1066, конечно, работала лучше за счёт микропрограммной поддержки и общей надёжности машины.
Например, как Вы на JCL собрались описывать несколько файлов на ленте, если Вы даже не знаете, сколько файлов девочка на СПД туда наколотила?
Никто теоретически не мешал сами эти операторы JCL сгенерить программно. Но это, конечно, изврат. Но в конечном итоге манипуляции в ассемблере с DSCB и DCB приводили к тому же.
По Вашему пруфу я нашел только о том, как конвертировать ISAM доступ из COBOL в VSAM. Про PL/I - ни слова.
Я лично много работал в СВМ на ЕС-1061. Она поддерживала машины, начиная с Ряда-2.
Даже не представляю, как ее туда удалось водрузить. НИЦЭВТ поставляло СВМ официально только для Ряд-3, а ЕС-1062 - Ряд-2. Поставлялась она вообще с SVS 6.1. На месте водружали TKS. По крайней мере даже в 1987 году, через два года после моего ухода на ПК, почти везде оставался TKS, если еще не штатный SVS 6.1.
Знаю о неудачной попытке водрузить СВМ на ЕС-1035 (тоже Ряд-2). Остались на TKS.
Никто теоретически не мешал сами эти операторы JCL сгенерить программно. Но это, конечно, изврат.
Очень интересно. Для COBOL или ассемблера делались пустые DD, которыми можно было динамически управлять. Но вот о том, что DD можно добавить уже после запуска задания на выполнение - слышу впервые. Тем более о таком механизме в PL/I.
По Вашему пруфу я нашел только о том, как конвертировать ISAM доступ из COBOL в VSAM. Про PL/I - ни слова.
Это ссылка на страницу документа Enterprise PL/I for z/OS Compiler and Run-Time Migration Guide, раздел Understanding the limitations of the new compiler.
Конкретно про использование ISAM можете почитать в руководстве по более старому компилятору, глава 9. Уже на тот момент ISAM поддерживался в режиме совместимости, так как его функции выполняет более новый VSAM.
Но вот о том, что DD можно добавить уже после запуска задания на выполнение - слышу впервые
Я имел в виду, что в одном задании можно подготовить второе задание. DD – это же просто текст на виртуальных перфокартах, которые сами по себе являются результатом работы какой-то программы.
По Вашему пруфу описана только ограниченная функциональность доступа к ISAM через VSAM.
Я к сожалению не могу сейчас найти документацию на PL/I образца 1983 года. Но точно помню, что с ISAM там были проблемы.
Я имел в виду, что в одном задании можно подготовить второе задание.
И сбрасывать принудительно все промежуточные данные на диск или ленту? Оригинально.
При этом Вы никак не назвали способ из PL/I все же посчитать количество файлов на ленте. Без этого как DD будете формировать?
не очень понимаю, чем в практическом смысле он отличается от присваивания структуры BY NAME
А где в структуре описать позиции блоков и субблоков на листе АЦПУ в которые должны выводиться данные? На несколько листов кто разбивать будет с корректным выводом итогов, подитогов, заголовков и футеров? Кодом программист? В COBOL это обеспечивал генератор отчетов сам, на основании декларативного описания. В PL/I - кодируй все процедурно.
Какая-нибудь многостраничная накладная, с подитогами на листах, с тремя переменными табличными блоками (один на всю ширину листа, два других под ним справа и слева) на COBOL делалась за час-два. На PL/I - за день не факт, что управишься.
Цузе имел безусловный приоритет в проектировании и создании первого в мире работающего программируемого компьютера, но не получил поддержки от немецко-фашистского государства и действовал как энтузиаст. В отличие от США и Великобритании, где работам по созданию компьютеров придавалось высшее государственное значение.
возможно главное это подтверждение, что создание компьютера к этому времени вполне назрело, ограниченность ресурсов Германии сыграло роль, ну и бомбежки под которые контора Zuse попала вместе со всеми, вообще правительство его работы финансировало (Aerodynamic Research Institute) и вполне было в курсе, Z3 был показан в Берлине в мае 1941, фотография реконструкции из музея в Мюнхене
Я понимаю так, что Цузе создал собственное ООО, которое на определённом этапе получило на коммерческой основе заказ от указанного института. А то, чтобы он, как Нейман и Тьюринг, был сотрудником государственного проекта.
несколько сложнее, в 1939 его призвали в армию, но фактически создали условия для работы, при этом продолжал работать в своем доме над Z2, Z3, и одновременно S1 и S2 специально для расчета аэродинамики планирующих бомб, в 1941 ему дали средства начать производства всего этого и основать компанию Zuse Apparatebau, которую финансировали через DVL (типа NASA), в 1944-45 начались бомбежки и все замедлилось,
интересно что еще в 1939 у него вместе с Schreyer были предложения перейти на лампы и пр. примерно как позже было сделано, но это не получило поддержки правительства
ps
в 1947 к нему приезжал Alan Turing и др. типа смотреть состояние дел
Не она ли в некоем суде, выступая в качестве свидетеля, на вопрос знает ли она что-либо о языках программирования ответила "Я его изобрела"? Или я что-то путаю?
Это история была про криптографию, если путаю
да, про патентных троллей. https://arstechnica.com/tech-policy/2013/11/newegg-trial-crypto-legend-diffie-takes-the-stand-to-knock-out-patent/
"We've heard a good bit in this courtroom about public key encryption," said Albright. "Are you familiar with that?"
"Yes, I am," said Diffie, in what surely qualified as the biggest understatement of the trial.
"And how is it that you're familiar with public key encryption?"
"I invented it."
«Идите и делайте, успеете оправдаться потом!»: история первой программистки с адмиральскими погонами