PL/1 - Programming Language One

← →
Sur © (2004-11-30 12:50) [0]

Недавно читал книгу, где было написано про язык PL/1. Этот язык программирования был разработан IBM-ом в 1964 году, но он значительно мощнее чем сегоднейшние C++, Pascal, ...
Ну кароче говоря я в восторге от этого языка. И мне интересно что об этом думают мастера.

← →
Sur © (2004-11-30 13:34) [1]

что никто не слышал про этот язык?

← →
boriskb © (2004-11-30 13:36) [2]

Программировал на нем лет 5-7. Могучайший язык. Реализация была не без глюков. А по замыслу - лучший для своего времени.

← →
Sur © (2004-11-30 13:42) [3]

а почему <<лучший для своего времени.>> ?

← →
boriskb © (2004-11-30 13:47) [4]

Сейчас понятие "язык программирования" означает немного не то, что в 70-80-е годы. Сейчас язык берет средой разработки.
Что Pascal без Turbo(сначала) и Delphi(позже) ? Так... один из многих...

← →
boriskb © (2004-11-30 14:10) [5]

boriskb © (30.11.04 13:47) [4]
Да и как сравнивать? А объектное программирование? Куда сейчас без него? (Хотя нафига оно нужно по большому счету?) А экранная графика? Тогда же даже понятий таких не было.

← →
Странник © (2004-11-30 14:29) [6]

Помню, помню. Классный язык, мощный.
С поддержкой БД.

← →
Юрий Зотов © (2004-11-30 14:53) [7]

Кому интересно - постарайтесь найти журнал Byte/Россия, №3 за 2000 год. Там неплохой обзор языков, с примерами кода. В том числе, и PL/1. В Инете точно видел перепечатки (правда уже довольно давно).

← →
ДедушкаКо (2004-11-30 14:54) [8]

во времена ЕС ЭВМ был массовым
на первых микропроцессорах- как PL/M
не прижился видать

штаны галифе тоже когда-то было "мощнее" :)

о поддержке БД не помню. да и самих БД в те времена тоже- только файлы ;)

← →
Anatoly Podgoretsky © (2004-11-30 15:02) [9]

ДедушкаКо (30.11.04 14:54) [8]
во времена ЕС ЭВМ был массовым на первых микропроцессорах- как PL/M

Не надо ставить знак равенства, ничего общего, кроме двух первых букв в названии, даже разработчики разные. PLM и PLM-16 тоже неплохии языки, мне нравились. Кроме того фирмой Интел на них были написаны и свои ОС, тоже хорошии, подход у Интел очень грамотный, это не лоскутный ДОС

← →
boriskb © (2004-11-30 15:08) [10]

ДедушкаКо (30.11.04 14:54) [8]
да и самих БД в те времена тоже- только файлы ;)

Круто :) Точно помнишь? Одно из двух - или очень уж старый и забыл или молодой и судишь по ... а черт его знают по чем молодые те времена судят :))

← →
Юрий Зотов © (2004-11-30 15:23) [11]

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

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

← →
boriskb © (2004-11-30 15:27) [12]

Юрий Зотов © (30.11.04 15:23) [11]

Я писал в ответ на
да и самих БД в те времена тоже- только файлы

← →
Dok_3D © (2004-11-30 15:45) [13]

И яяя... программировал на нем. Можно даже сказать что много.
Насчет значительно мощнее чем сегоднейшние C++ - как тут сравнить? Он даже не объектно-ориентированный.
Да компы были - EC-1045. Содранные в IBM-360. Старье ...
Похож на Pascal.

← →
boriskb © (2004-11-30 15:50) [14]

Dok_3D © (30.11.04 15:45) [13]
Похож на Pascal.

Это что-то уже...
Чем же это похож? :) IF then есть и там и там? :))

← →
MOA © (2004-11-30 15:53) [15]

Кстати, PL-1 известен как классический пример неудачного подхода к построению языка. Дело в том, что он был задуман как "язык для всего" - как бы и FORTRAN и COBOL (видимо, это имелось в виду по поддержкой БД) и ALGOL в одном флаконе. В нём пытались предусмотреть всё и сделать удобным для всего (ну, например, кроме передачи параметров по ссылке, там можно передавать и по имени).Посему получился чертовски большим. Опять же, классическая фраза "ни один программист знает PL-1 полностью". Средний программист использовал 5-10% (нужной части) языка - хватало ;).
Провал PL-1 привёл к тому, что теперь таких "языков-для-всего" больше не "выделывают" ;). Очень поучительный оказался пример. ;).

← →
boriskb © (2004-11-30 15:58) [16]

MOA © (30.11.04 15:53) [15]
Кстати, PL-1 известен как классический пример неудачного подхода к построению языка.

Не знаю насчет классического примера. Действительно и
MOA © (30.11.04 15:53) [15]
получился чертовски большим
и
MOA © (30.11.04 15:53) [15]
"ни один программист знает PL-1 полностью".
все правда. Но пользоваться им было удобно. :)

← →
Юрий Зотов © (2004-11-30 16:25) [17]

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

← →
boriskb © (2004-11-30 16:40) [18]

Юрий Зотов © (30.11.04 15:23) [11]
Но ведь это еще не БД, саму БД все равно нужно было делать ручками.

ADABAS (по моему немецкий) интерфейс с PL/I был.

← →
Sha © (2004-11-30 17:16) [19]

Еще у PL/1 были 2 версии компилятора: обычный и ортимизирующий (PL/I Optimizer).
Тот оптимизатор, который встроен в Delphi - детская игрушка по сравнению с PL/I.
Умели делать...

← →
ДедушкаКо (2004-11-30 17:22) [20]

> ADABAS (по моему немецкий) интерфейс с PL/I был.

ага, АДАБАС на 33 или 45, которых было большинство

теоретически были и базы, и банки данных
может где-то они и работали, штук 10 на союз

← →
boriskb © (2004-11-30 17:28) [21]

ДедушкаКо (30.11.04 17:22) [20]
может где-то они и работали, штук 10 на союз
В средьмаше adabas был стандартом. А средьмаш это... огого :)

← →
Игорь Шевченко © (2004-11-30 19:52) [22]

boriskb © (30.11.04 15:58) [16]

> Но пользоваться им было удобно. :)

Потому что больше ничего не было :) Язык PL/1 отличался, как говорят, избыточной монстровостью, потому как более неудобной смеси Фортрана, Алгола и Кобола придумать очень трудно :)

boriskb © (30.11.04 16:40) [18]

> ADABAS (по моему немецкий) интерфейс с PL/I был.

Ну вот, мою первую любовь вспомнили...:) Был интерфейс с PL/1. И с Коболом был и с ассемблером.

← →
DrPass © (2004-11-30 22:57) [23]

Есть такая поговорка, что даже в IBM нет людей, которые знают весь PL/1

← →
iZEN © (2004-11-30 23:57) [24]

/**Юрий Зотов © (30.11.04 16:25) [17]
Во всяком случае, в PL/1 было несколько примочек, которых сейчас иногда не хватает и приходится делать их либо ручками, либо использовать API. Например, переменные CONTROLLED, встроенная прямо в язык поддержка мультизадачности, очень удобная обработка исключений...
*/
Король умер, да здравствует король!
Есть ADA95:
+ компактный (про то, что сложный - бред) ортогональный и универсальный язык с Pascal-подобным синтаксисом;
+ жёсткий стандарт;
+ надёжность, управляемость, модульность, переносимость;
+ раздельная компиляция;
+ объектно-ориентированность с мощным механизмом параллельного исполнения, обработка исключительных ситуаций - всё встроено в язык, а не в библиотеки (не как в Java).

http://www.osp.ru/os/1997/03/52_print.htm
http://qnxclub.net/files/articles/razm/razm.html

Так PL/1 по сравнению с Адой отдыхает?

← →
Cobalt © (2004-12-01 03:09) [25]

> MOA © (30.11.04 15:53) [15]
> по поддержкой БД
> В нём пытались предусмотреть всё и сделать удобным для всего (ну, например, кроме передачи параметров по ссылке, там можно передавать и по имени).

Знаете, я сейчас пишу на языке М, так вот - очень уж, по этим словам, напоминает :)
И ничего, очень удобный. Даже объектный.

← →
Юрий Зотов © (2004-12-01 08:26) [26]

> iZEN © (30.11.04 23:57) [24]

> Так PL/1 по сравнению с Адой отдыхает?

Трудно сравнивать. Я не знаю Аду, а Вы, похоже, не знаете PL/1, так что получится у нас, что называется "разговор слепого с глухим". Конечно, PL/1 - язык старый (он старше Ады лет на 15) и в нем нет многого из того, что появилось в более поздних языках (кстати, очень даже может быть, что некоторые из новшеств появились в них именно благодаря примеру PL/1). Но, зная PL/1 (и даже еще немного его помня), я все же сомневаюсь в том, что по сравнению с другими языками он так уж сильно "отдыхает". Потому что действительно очень мощный (отчасти, наверное, даже в чем-то революционный) был язык (и в то время по сравнению с ним "отдыхали" как раз другие языки).

Если есть желание, давайте поступим так. В журнале, на который я ссылался выше, обзор каждого языка писался отдельным автором - и в качестве иллюстрации каждый автор давал на этом языке код, решающий одну и ту же задачку, заранее сформулированную редакцией. Задачка достаточно простая (чтобы минимально откомментированный код был понятен всем, даже не знающим языка), но все же посложнее, чем A:=B+C (чтобы было на чем показать какие-то возможности языка).

Мне кажется, это неплохой способ. Поэтому предлагаю написать прямо здесь два решения этой же самой задачки. Вы напишете на Аде, я напишу на PL/1 - вот тогда и сами сравним, и послушаем, что скажут другие. Задачка формулируется так.

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

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

← →
boriskb © (2004-12-01 08:41) [27]

Юрий Зотов © (01.12.04 8:26) [26]

Это было бы здорово!
Юрий, у меня просьба - выложи пожалуйста свой вариант на PL/I в любом случае.
Может примеры и на других языках (желательно не очень популярных сейчас)появятся. Будет просто шикарная ветка.

← →
MBo © (2004-12-01 09:41) [28]

Паскальный вариант ;)

program Project5; {$APPTYPE CONSOLE} type PNode = ^TNode; TNode = record Next: PNode; Data: Integer; end; var Cnt, i: Integer; InArr: array of Integer; Tail, Node: PNode; begin //auto input generation Randomize; Cnt := 5+Random(10); SetLength(InArr, Cnt); for i := 0 to Cnt - 1 do begin InArr[i] := Random(100); Writeln(InArr[i]); end; //input treatment Tail := nil; for i := 0 to Cnt - 1 do if Odd(InArr[i]) then begin New(Node); Node.Next := Tail; Node.Data := InArr[i]; Tail := Node; end; //final stage Writeln; while Tail <> nil do begin Writeln(Node.Data); Node := Node.Next; Dispose(Tail); Tail := Node; end; Readln; end.

← →
Sha © (2004-12-01 09:48) [29]

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

Насчет незнания его полностью. Нормальные программисты знали его как раз полностью за счет отличного документирования фирмой IBM своих продуктов. А новичкам, которым ставились задачи соответсвенно их силам, для их решения было достаточно знать стандартные возможности (ввод/вывод, структура программ и данных). Язык можно было учить постепенно.

← →
Sha © (2004-12-01 09:51) [30]

соответственно

← →
boriskb © (2004-12-01 10:01) [31]

Sha © (01.12.04 9:48) [29]
Ни один из тех, кто его по-настоящему использовал, не назовет его неудобным, сложным или как-то еще.

Другими словами И.Ш. - врун? :) :)
Игорь Шевченко © (30.11.04 19:52) [22]
как более неудобной смеси Фортрана, Алгола и Кобола придумать очень трудно :)
Так и говори без экивоков :)

← →
Игорь Шевченко © (2004-12-01 10:08) [32]

Sha © (01.12.04 09:48) [29]

> PL/1 - классный язык. Ни один из тех, кто его по-настоящему
> использовал, не назовет его неудобным, сложным или как-то
> еще.

Я назову. Использовал его 7 лет. В то время, когда использовал, был согласен с твоей оценкой. После того, как познакомился с другими языками (С, впоследствии Паскаль), выработал свою оценку [22]

С уважением,

← →
ocean (2004-12-01 10:16) [33]

Да, классный был язык, что говорить. И небо было выше, и трава зеленее... Но сейчас мне кажется, что Паскаль и С (имею в виду стандарты Вирта и Кернигана) четче и элегантнее.
Кстати, в те времена были и другие вещи, незаслуженно забытые

← →
REA (2004-12-01 10:18) [34]

Дельфовый вариант:
Var
Stack: TStack;
i, Cnt: Integer;
Begin
Randomize;
Cnt := Random(10);
With TStack.Create() Do
Try
For i := 0 To Cnt Do
Stack.Push(Pointer(Random(100)));
While Count>0 Do
Begin
i := Integer(Stack.Pop());
If (i And 1)<>0 Then WriteLn(i);
End;
Finally
Free;
End;
End;

← →
REA (2004-12-01 10:24) [35]

Точнее так
Var i, Cnt: Integer;
Begin
Randomize;
Cnt := Random(10);
With TStack.Create() Do
Try
For i := 0 To Cnt Do
Push(Pointer(Random(100)));
While Count>0 Do
Begin
i := Integer(Pop());
If (i And 1)<>0 Then WriteLn(i);
End;
Finally
Free;
End;
End;

← →
Юрий Зотов © (2004-12-01 10:29) [36]

Да, упустил из виду еще один критерий (по значимости, видимо, его нужно поставить на второе место):
- эффективность кода (по требуемой памяти и скорости работы).

> Sha © (01.12.04 09:48) [29]

Готов подписаться под каждым словом. Язык был действительно сложным - но он становился сложным только в сложных же задачах, требующих использования его примочек (которые, кстати, задачу упрощали). А в простых задачах он был ничуть не сложнее других языков (возможно, даже проще - например, вычислительные программы писались на PL/1 практически так же, как и на Фортране, но выглядели намного читабельнее).

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

← →
Sha © (2004-12-01 10:44) [37]

> Игорь Шевченко © (01.12.04 10:08) [32]

> Я назову. Использовал его 7 лет. В то время, когда
> использовал, был согласен с твоей оценкой. После того, как
> познакомился с другими языками (С, впоследствии Паскаль),
> выработал свою оценку [22]

Эти тоже неплохи по своему, мое первое впечатление от них было:
С - стройнее, но менее защищен,
Паскаль - защищеннее, но сковывает инициативу.

Потом и к ним привык :)

С уважением.

← →
iZEN © (2004-12-01 19:52) [38]

to MBo © (01.12.04 09:41) [28]
Вариант на Java:public class Project5 { private static class Node { private Node next; private int data; } public static void main(String[] args) { //auto input generation int cnt = (int)(100 * Math.random()); int[] inArr = new int[cnt]; for (int i = 0; i < cnt; i++) { inArr[i] = (int)(100 * Math.random()); System.out.println(inArr[i]); } //input treatment Node tail = null; for (int i = 0; i < cnt; i++) { if (inArr[i] % 2 != 0) { Node node = new Node(); node.next = tail; node.data = inArr[i]; tail = node; } } //final stage System.out.println(); while (tail != null) { Node node = tail; System.out.println(node.data); node = node.next; tail = node; } } }

← →
iZEN © (2004-12-01 19:53) [39]

К большому сожалению ADA95 я не знаю. С этим языком начал разбираться только-только.

← →
iZEN © (2004-12-01 20:13) [40]

К [38].
Так получше://final stage System.out.println(); while (tail != null) { Node node = tail; System.out.println(node.data); tail = node.next; }

← →
wicked © (2004-12-01 20:26) [41]

на си++:

#include <deque> #include <iostream> #include <iomanip> void x() { int count = rand(); // input generation vector<int> inp(count, 0); for(int * i = inp.begin(); i < inp.end(); i++){ *i = rand(); cout << *i << endl; } // input treatment deque<int> outp; for(int * i = inp.begin(); i < inp.end(); i++) if(*i % 2) outp.push_front(*i); // output cout << endl; for(deque<int>::iterator i = outp.begin(); i < outp.end(); i++) cout << i[0] << endl; }

← →
wicked © (2004-12-01 20:27) [42]

в догонку:
не самый эффективный вариант.... плюс использовался STL - своего рода удар ниже пояса... ;)

← →
iZEN © (2004-12-01 21:21) [43]

Так это, использование высокоуровневых библиотек (типа STL) вроде бы не есть сравнение.
Давайте сравнивать возможности языка, соответственно, и задачки должны быть направлены на это - на выявление выразительных возможностей языка.

← →
wicked © (2004-12-01 21:33) [44]

хотя с другой стороны, если не использовать (стандартные) библиотеки, то все си/паскале-подобные языки превратятся в банальные высокоуровневые ассемблеры....

← →
iZEN © (2004-12-01 23:42) [45]

to wicked © (01.12.04 21:33) [44].
Возможно Вы и правы, но в этом может проявится истинная мощь языка, отделённая от всяческих дополнительных библиотек.

Для оценки языков предлагаю следующее.
Итак, для Pascal необходимым и достаточным условием является использование системно-языковой библиотеки-модуля System.
Для Java необходимым и достаточным условием является использование системно-языковой библиотеки-пакета java.lang.*.
Для C/C++ <напишите сами> (я затрудняюсь идентифицировать системные вещи в этом языке)
Для другого языка...<напишите сами>

Что мы в этом случае имеем в "сухом остатке"?
Приводите примеры и думайте.

← →
Жан-Поль Петров (2004-12-02 06:19) [46]

REA (01.12.04 10:18) [34]

да, стек rulez :)
первое, что пришло мне в голову, был массив :(
----------------------------------------------

предлагаю сишный вариант (с рекурсией)

#include <stdio.h> main() { long i; if (scanf ("%ld", &i) != 1) exit (0); fflush (stdin); if (i & 1L) main (); else return 0; printf ("%ld\n", i); return 0; }

:)

← →
Юрий Зотов © (2004-12-02 10:23) [47]

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

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

Суть этой фичи в том, что для каждой такой переменной автоматически организуется ее собственный персональный стек. ALLOCATE создает и заталкивает в этот стек новый экземпляр переменной, FREE выталкивает из стека верхний экземпляр и уничтожает его, а ALLOCATION проверяет, не пуст ли стек. И для рассматриваемой задачи такая языковая фича идеальна - просто и эффективно, не надо ничего делать ручками и не нужны никакие библиотеки, все есть в самом языке.

Другая языковая фича PL/1, которая в этой задаче очень полезна (и тоже дает простую и эффективную реализацию) - это, говоря по-современному, структурная обработка исключений (тоже встроенная в сам язык и, насколько я понимаю, как раз и ставшая первой реализацией того, что сейчас называют SEH). И надо сказать, что (опять же, на мой взгляд) реализация SEH в PL/1 была более мощной, гибкой и удобной по сравнению, например, с современными C или Delphi.

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

PL1_EXAMPLE: PROCEDURE OPTIONS(MAIN); DECLARE I CONTROLLED; ON ENDFILE(SYSIN) BEGIN FREE I; GOTO L2; END; L1: ALLOCATE I; GET LIST(I); IF MOD(I,2)=0 THEN FREE I; GOTO L1; L2: DO WHILE(ALLOCATION(I)); PUT LIST(I); FREE(I); END; END PL1_EXAMPLE;

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

Тем, кто заинтересовался языком PL/1, могу порекомендовать заглянуть сюда:
http://www-306.ibm.com/software/awdtools/pli
Там Вы найдете... PL/1 для Windows (Visual Age PL/1) и не только.

← →
REA (2004-12-02 10:41) [48]

>прост и прозрачен

Ню ню. Лично я после первого прочтения понял половину. Особенно GOTO L2 настораживает.

← →
Юрий Зотов © (2004-12-02 11:37) [49]

> REA (02.12.04 10:41) [48]

GOTO настораживает, если есть приверженность к догмам. Вычитал человек в книжке, что GOTO - это плохо, что это лишнее, что это ухудшает читабельность программы, и.т.д. - и все! И стоит на том.

А ведь это всего лишь догма, не более. Насчет "лишнее" - так лишние операторы есть практически в любом языке (на фига в Паскале аж 3 вида циклов, когда одного while вполне достаточно?). Насчет "ухудшает" - если использовать с умом, то не ухудшает, а может даже и улучшить. И т.д.

Тут надо подходить с обычной здравой позиции, что "всякий овощ полезен, будучи употреблен в свое время". Ведь JMP в ассемблере никого не смущает? Нет. Вот так же и в ЯВУ - в том же Паскале я уже забыл, когда последний раз писал GOTO (кажется, за 15 лет вообще ни разу не писал), но если завтра я вдруг увижу, что в каком-то месте программы один маленький GOTO заменяет кучу кода, дает наиболее эффективную реализацию и не ухудшает читабельность - я тут же влеплю в этом месте GOTO. И буду прав.

← →
Sha © (2004-12-02 11:58) [50]

> Юрий Зотов © (02.12.04 10:23) [47]
> Не могу гарантировать, что в программе нет ошибок

Одна точно есть. Отсутствует точка с запятой после BEGIN :)

Еще, насколько помню, более эффективный (и для меня более понятный)
код получается, если блок обработки конца файла не использовать,
а только указать, куда идти при возникновении конца файла. Этот
адрес будет сразу помещен компилятором в соответствующий блок DCB.

PL1_EXAMPLE: PROCEDURE OPTIONS(MAIN); DECLARE I CONTROLLED; ON ENDFILE(SYSIN) GOTO L2; L1: ALLOCATE I; GET LIST(I); IF MOD(I,2)=0 THEN FREE I; GOTO L1; L2: FREE I; DO WHILE(ALLOCATION(I)); PUT LIST(I); FREE(I); END; END PL1_EXAMPLE;

← →
boriskb © (2004-12-02 12:17) [51]

Юрий Зотов
Sha
У меня к вам вопрос. Вы писали этот пример не освежая в памяти синтаксис? Или заглянули в книгу/инет?
Читая по писанному - вроде все вспомнилось, но сам написать не освежая память ни за что бы не смог :)
Если вы смогли - снимаю шляпу,которую не ношу :)

← →
begin...end © (2004-12-02 12:19) [52]

> [49] Юрий Зотов © (02.12.04 11:37)

> Насчет "лишнее" - так лишние операторы есть практически
> в любом языке (на фига в Паскале аж 3 вида циклов, когда
> одного while вполне достаточно?).

Юрий, вот мне просто очень интересно Ваше мнение.
Может быть, Вы читали эту ветку:

http://delphimaster.net/view/1-1100705690/

Если не трудно, скажите, какой из вариантов кода в той ветке - [17] (на странице 1) или [132] (на странице 7) Вы бы предпочли?

← →
REA (2004-12-02 12:19) [53]

>Ведь JMP в ассемблере никого не смущает?

А там другого и нет. Меня впрочем смущает не само наличие GOTO, а то что я не понял в какой последовательности выполняются операторы. Я не отрицаю, что язык мощный, но вот насчет "прозрачности" это пожалуй не лучший пример.
Со второго прочтения конечно ясно, что язык позволяет назначить некую обработку события (ON), но на мой взгляд логичнее описать процедуру обработчика ONENDFILE(SYSIN). Однако не буду спорить с разработчиками языка о реализации событий - уже одно то, что они есть, в отличии от многих языков того времени заслуживает уважения.

← →
REA (2004-12-02 12:24) [54]

А, это видимо и есть процедура (я по второму коду смотрел).
Тем более непонятно, зачем GOTO, если можно все прямо там и сделать.

← →
boriskb © (2004-12-02 12:29) [55]

REA (02.12.04 12:24) [54]
Насколько я помню, это был просто общепринятый стандарт. Своя логика была - все обработчики исключений всегда в конце кода.
Писать обработчик сразу за ON считалось дурным тоном.

← →
boriskb © (2004-12-02 12:34) [56]

Юрий Зотов © (02.12.04 11:37) [49]
я тут же влеплю в этом месте GOTO. И буду прав.

Если кто будет спорить, то не с тобой, а с Дейкстрой и Йоданом :)

← →
KSergey © (2004-12-02 12:58) [57]

> [42] wicked © (01.12.04 20:27)
> не самый эффективный вариант.... плюс использовался STL
> - своего рода удар ниже пояса... ;)

Вообще-то STL входит в стандарт языка и, хотя не является языковым средством а как-бы внешней библиотекой - однако точно так же можно запретить использование каких-то "фич" PL/1... Хотя они и входят в сам язык, конечно. Зато на C++ эти фичи можно создавать, что является все же плюсом языка по моему мнению..

← →
Странник © (2004-12-02 13:44) [58]

> Юрий Зотов © (30.11.04 15:23) [11]
ну естесственно, поддержки современных СУБД в PL/1 еще не было :)
я имел ввиду именно поддержку всех 4-х методов доступа.

и не только CONTROLLED переменные и ON ситуации, было много других классных вещей. Многое уже забылось, последний программа на PL/1 - 1989 год.

← →
wicked © (2004-12-02 14:17) [59]

> KSergey © (02.12.04 12:58) [57]

> Вообще-то STL входит в стандарт языка и, хотя не является
> языковым средством а как-бы внешней библиотекой - однако
> точно так же можно запретить использование каких-то "фич"
> PL/1... Хотя они и входят в сам язык, конечно. Зато на C++
> эти фичи можно создавать, что является все же плюсом языка
> по моему мнению..

именно это я и имел в виду - вынесение фич из языка в библиотеки... а в совокупности (язык + "рекомендуемые" библиотеки) их вполне наберется в разы больше... например, для си++ это будет язык + библиотеки си + библиотеки си++ + STL + (возможно) Boost + (если это BCB) VCL...
хотя чую, что это уже оффтопик... или философия.... ;)

← →
KSergey © (2004-12-02 14:20) [60]

> [59] wicked © (02.12.04 14:17)
> (возможно) Boost + (если это BCB) VCL...

Нет, это уже библиотеки определенной поставки, это не скандарт языка. STL - стандартизируемая вещь.

← →
Sha © (2004-12-02 15:02) [61]

> boriskb © (02.12.04 12:17) [51]
> Вы писали этот пример не освежая в памяти синтаксис?

Я все честно списал у Юрия Зотова [47].

← →
Sha © (2004-12-02 15:14) [62]

> REA (02.12.04 12:24) [54]
> Тем более непонятно, зачем GOTO, если можно все прямо там и сделать.

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

← →
Sandman25 © (2004-12-02 16:20) [63]

[62] Sha © (02.12.04 15:14)

Есть нечто похожее в Informix-4GL

ON {ERROR|SQLERROR} {CONTINUE|STOP|GOTO label|CALL function}

← →
Sandman25 © (2004-12-02 16:47) [64]

[63] Sandman25 © (02.12.04 16:20)

Точнее

WHENEVER {ERROR|SQLERROR} {CONTINUE|STOP|GOTO label|CALL function}

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

← →
Юрий Зотов © (2004-12-02 20:14) [65]

> Sha © (02.12.04 11:58) [50]

1. Есть еще одна: FREE(I);
:о)
2. Так лучше, конечно.

> boriskb © (02.12.04 12:17) [51]

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

> begin...end © (02.12.04 12:19) [52]

Я бы предпочел [17]. Код [132] медленнее и не так прозрачен.

Только в [17] я бы гнал бы цикл не от 0, а от Low. Мало ли, что изменится в будущих версиях - вдруг нижняя граница станет не обязательно нулем?

> REA (02.12.04 12:19) [53]
> логичнее описать процедуру обработчика ONENDFILE(SYSIN).

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

Так вот, конструкция
ON <исключение> BEGIN; ... END;
определяет не что-нибудь, а именно блок, который будет выполнен при возникновении этого исключения. И к этому блоку применимы все те же правила - он может содержать любой код собственные переменные, и вложенные блоки. То есть, фактически, это и есть подпрограмма, вызываемая при возникновении исключения - именно то, что Вы и сказали. Так что все логично и очень гибко: хочешь - пиши begin-end и делай обработчик в виде блока, хочешь - напиши в нем CALL и вызови подпрограмму, а хочешь - напиши GOTO и сам распорядись передачей управления (см. [62]).

Вообще, PL/1 был ОЧЕНЬ логичен (что тоже помогало довольно легко понимать и запоминать конструкции языка, несмотря на их обилие и сложность) и давал программеру ОЧЕНЬ много свободы (даже, пожалуй, СЛИШКОМ много, я после него на Паскаль просто плевался и только потом понял, что строгость и типизированность Паскаля - это его огромное достоинство, а вовсе не недостаток). Можно сказать, что компилятор PL/1 правильно распознавал чуть ли не ЛЮБУЮ однозначную конструкцию. Вот пример:
S1="ВАСЯ ЕСТ ПРЯНИК"; S2=SUBSTR(S1,10,6); /* ВЗЯТИЕ ПОДСТРОКИ. ТЕПЕРЬ S2="ПРЯНИК" */ SUBSTR(S1,10,4)="БУБЛ"; /* ФУНКЦИЯ В ЛЕВОЙ ЧАСТИ !!! */ S2=SUBSTR(S1,10,6); /* А ТЕПЕРЬ S2="БУБЛИК" */

> KSergey © (02.12.04 12:58) [57]
> так же можно запретить использование каких-то "фич" PL/1...
> Хотя они и входят в сам язык, конечно. Зато на C++ эти фичи
> можно создавать, что является все же плюсом языка по моему
> мнению..

Как же можно запретить то, что реализовано в самом компиляторе? Никак не запретишь, запретить можно только то, что поддерживается за счет внешних библиотек. А создавать фичи (то есть, писать собственные библиотеки) можно на любом языке, так что это и не фичи ЯЗЫКА, и даже вообще не плюс.

← →
wicked © (2004-12-02 20:29) [66]

> Юрий Зотов © (02.12.04 20:14) [65]

> Как же можно запретить то, что реализовано в самом компиляторе?
> Никак не запретишь, запретить можно только то, что поддерживается
> за счет внешних библиотек. А создавать фичи (то есть, писать
> собственные библиотеки) можно на любом языке, так что это
> и не фичи ЯЗЫКА, и даже вообще не плюс.

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

> wicked © (02.12.04 20:29) [66]

Не совсем так. Во-первых, некоторые процедуры и функции могут быть "зашиты" в сам компилятор (как SizeOf в Паскале). Во-вторых, есть такое понятие - библиотека компилятора. Это набор процедур и функций, входящих в официальное описание языка, поставляемый вместе с компилятором и являющийся его неотъемлемой частью (как модуль System в TP или в Delphi) - то есть, фактически, этот набор процедур и функций является как бы модулем компилятора и поэтому тоже принадлежит самому языку.

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

Можно, и мои пять копеек? ;).
Вот в этом, ПМСМ, всё и дело. На ранних стадиях науки "информатика" пытались сделать в языке все основные абстракции. "Список", "Дерево", "Стек", "Очередь" ... Соответственно - обязаны реализовать операции над этими типами данных. И вот тут и трудность - полезные структуры данных множатся + набор "общепринятых" базовых операций может и измениться + запросто могут появится и другие, не менее полезные структуры.
Выход был найден - либо реализацией в языке базовой функциональности с неслабой поддержкой подпрограмм (библиотек, пакетов и т.д.) - C, C++, Modula - либо "выдумыванием" некоей "универсальной" структуры - из которой "как бы" выводятся (ну, или можно "естественно построить") все остальные структуры - Lisp, Prolog.
В любом случае - оказалось, что язык должен быть достаточно "мал" для "осмысления" его программистом. Вспоминается правило (м.б., я и ошибаюсь - но приведу): "у программиста не должно быть больше 4-х путей решения его задачи". Поскольку большее число альтернатив мозг нормального человека оценить не в силах ;).

> Юрий Зотов © (02.12.04 20:14) [65]
> SUBSTR(S1,10,4)="БУБЛ"; /* ФУНКЦИЯ В ЛЕВОЙ ЧАСТИ !!! */
В М-е похожая фигня:
write str > error "Undefined" <- переменная неопределена s $piece(str,"~",2)="two" write str > ~two s $piece(str,"~",6)="six" write str > ~two~~~~six

>Юрий Зотов © (01.12.04 08:26) [26]

>Стандартный входной поток содержит произвольное (и заранее не >известное) количество целых чисел. Нужно все их прочитать, а >затем вывести нечетные числа в стандартный выходной поток в >порядке, обратном исходному. Чтобы "не заслонять лес деревьями", >будем считать, что доступная память бесконечна.

Вот как это решение будет выглядеть в SAP R/3 на языке ABAP.
Я только сделаю одно допущение. Так как в SAP источником данных является БД, то вместо стандартного входного потока будет использоваться таблица некая таблица STDIN, содержащая целочисленное поле DATA. В качестве выходного потока будет использоваться вывод на экран.
REPORT abap_example. DATA: values TYPE STANDARD TABLE OF stdin-data WITH HEADER LINE, frac TYPE I. START-OF-SELECTION. SELECT data INTO TABLE values FROM stdin ORDER BY belnr DESCENDING . END-OF-SELECTION. LOOP AT values. frac = values MOD 2. IF frac <> 0. WRITE / values. ENDIF. ENDLOOP.

Пример на ADA будет опубликован?

В качестве прикола. Входные данные - с клавиатуры, вывод - на экран. Конец последовательности - строка end. Ограничения - размер стека. :o)

program Project1; {$APPTYPE CONSOLE} procedure DoIt; var s: string; begin readln(s); if s <> "end" then DoIt writeln(s); end; begin DoIt; readln; end.

";" не хватало.

procedure DoIt; var s: string; begin readln(s); if s <> "end" then DoIt; writeln(s); end;

/**euru © (03.12.04 17:04) [71]
Пример на ADA будет опубликован?
*/
Нашёл ObjectAda for Win95 на старинном диске - пока буду изучать.
(Заинтересовало то, что там есть прозрачный маппинг на Java 1.0.2 - глянул исходники. Вот только каталог с дистрибутивом, видимо, из-под DOS копировали - имена файлов обрезаны - придётся восстанавливать...)

Для затравки:
http://www.computer-museum.ru/histsoft/ada20.htm

1.Хорошо известен компилятор GNAT Ada 95 от
Free Software Foundation, Inc.
http://www.gnat.com/ada_2005.php

2.A# is a port of Ada to the Microsoft .NET Platform

Книги по ADA
http://faqs.org.ru/progr/other_l/adafaq2.htm

Sha © (01.12.04 09:48) [29]
PL/1 - классный язык. Ни один из тех, кто его по-настоящему использовал, не назовет его неудобным, сложным или как-то еще.

Насчет незнания его полностью. Нормальные программисты знали его как раз полностью за счет отличного документирования фирмой IBM своих продуктов. А новичкам, которым ставились задачи соответсвенно их силам, для их решения было достаточно знать стандартные возможности (ввод/вывод, структура программ и данных). Язык можно было учить постепенно.

PL/1 - неправильный и неудачный язык. Напоминает лоскутное одеяло. Куча фич, которые притянуты за уши. Никто никогда не знал его полностью. Невооруженным глазом видно, что разрабатывался он большой разрозненной командой, в которой один отдел не знал, что делает другой. ОЧЕНЬ неортогональный и избыточный синтакс, в этом с ним может конкурировать разве что Perl. ОЧЕНЬ контекстозависимый - одно и то же в разных контекстах может означать разные вещи, а то и вовсе быть некорректным. Как следствие - громоздкий компилятор. Платформоориентированный, а потому непереносимый.

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

"Полезно взглянуть на два языка программирования - PL/1 и C. Язык PL/1 был разработан корпорацией IBM в 60-ые годы, так как поддерживать одновременно FORTRAN и COBOL и слушать при этом ворчание ученых о том, что Algol лучше, чем FORTRAN и COBOL, вместе взятые, было невыносимо. Поэтому был создан комитет для создания нового языка, удовлетворяющего запросам всех программистов: PL/1.
Этот язык обладал некоторыми чертами языка FORTRAN, некоторыми особенностями языка COBOL и некоторыми свойствами языка Algol. Проект потерпел неудачу, потому что ему недоставало единой концепции. Проект представлял собой лишь набор свойств, конфликтующих друг с другом, к тому же язык PL/1 был слишком
громоздким и неуклюжим, чтобы программы на нем можно было эффективно компилировать.
Теперь взглянем на язык С. Он был спроектирован всего одним человеком (Деннисом Ритчи) для единственной цели (системного программирования). Успех его был колоссален, и это не в последнюю очередь объяснялось тем, что Ритчи знал, чего хотел и чего не хотел. В результате спустя десятилетия после своего появления этот язык все еще широко распространен. Наличие четкого представления о своих целях является решающим."

(с) Эндрю Таненбаум

> Наличие четкого представления о своих целях является решающим

Фраза христоматийная.
Философская, если хотите.

Никлас Вирт тоже был в этом смысле философом. Спаибо Борланду, что не забыл старика Вирта.....

"Язык PL/I представляет собой первую масштабную попытку разработки языка, кото¬рый бы использовался в широком спектре областей. Все предшествовавшие и большин¬ство последующих языков программирования концентрировались на какой-то одной об¬ласти применения (наука, искусственный интеллект или коммерция).
2.8.1. Исторические предпосылки
Подобно языку FORTRAN язык PL/I разрабатывался как продукт корпорации IBM. В начале 1960-х годах промышленные пользователи компьютеров сформировали два от¬дельных лагеря. С точки зрения корпорации IBM научные программисты могли исполь¬зовать либо универсальный компьютер 7090, либо компьютер с ограниченными возмож¬ностями 1620, которые выпускались указанной корпорацией. Эта группа в значительной степени использовала тип данных с плавающей точкой и массивы. Основным языком в их работе был язык FORTRAN, хотя параллельно рассматривались и некоторые языки ассемблера. Эти пользователи имели собственную группу SHARE и поддерживали сла¬бые связи с программистами, работавшими над коммерческими приложениями.
Для коммерческих приложений использовались большие или малые компьютеры, IBM 7080 и IBM 1401. Для этих приложений требовались типы данных для десятичных чисел и символьных строк, а также детально разработанные и эффективные свойства ввода-вывода. Данная группа пользователей использовала язык COBOL, хотя в начале 1963 года переход с языков ассемблера на язык COBOL был далек от завершения. Эта категория пользователей также имела свою собственную группу пользователей GUIDE и изредка налаживала контакты с научными пользователями.
В начале 1963 года проектировщики корпорации IBM почувствовали, что ситуация начинает меняться. Указанные группы двигались навстречу друг другу по путям, кото¬рые неизбежно должны были привести к возникновению проблем. Ученые начали соби¬рать большие файлы данных, требующих обработки. Для этого нужны были изощренные и эффективные средства ввода-вывода. Люди же, занимавшиеся коммерческими прило¬жениями, для построения систем управления информацией начали использовать регрес¬сионный анализ, что требовало чисел с плавающей точкой и массивов. Стало казаться, что внедрение компьютерной техники вскоре потребует двух отдельных компьютеров, поддерживающих два значительно отличающихся языка программирования.
Эти предчувствия вполне естественно привели к возникновению концепции разра¬ботки единого универсального компьютера, который бы мог выполнять как действия над числами с плавающей точкой, так и над десятичными числами, и, следовательно, был бы применим и в науке, и в коммерции. Так зародилась концепция серии компьюте¬ров IBM System/360. Наряду с этой концепцией возникла идея о языке программирова¬ния, который был бы применим и для коммерческих, и для научных приложений. В зна¬чительной степени в язык были включены возможности системного программирования и обработки списков. Следовательно, новый язык должен был заменить языки FORTRAN, COBOL и LISP, а в области системных приложений — еще и язык ассемблера."
...продолжение следует...

...продолжение...
"2.8.2. Процесс разработки
Разработка началась с образования в октябре 1963 года корпорацией IBM и группой SHARE комитета Advanced Language Development Committee of the SHARE FORTRAN Project. Этот новый комитет быстро собрался и сформировал подкомитет 3<->3 Committee, названный так из-за наличия в нем трех человек со стороны корпорации IBM и трех со стороны группы SHARE. Для разработки языка комитет 3<->3 Committee соби¬рался на три-четыре дня через неделю.
Как и при работе комитета Short Range Committee, разрабатывавшего язык COBOL, завершение исходной разработки была запланировано на удивительно близкую дату. По-видимому, независимо от целей разработки языка в начале 1960-х широко распростра¬ненно мнение, что это задание может быть выполнено за три месяца. Первую версию языка PL/I, позже названную FORTRAN VI, предполагалось завершить к декабрю, что составляло менее трех месяцев со дня основания комитета. Комитет, приведя в оправда¬ние две различные причины задержки, передвинул срок окончания работ сначала на ян¬варь, а затем и на февраль 1964 года.
Исходная концепция разработки состояла в том, что новый язык должен был быть расширенной версией языка FORTRAN IV, совместимой с ним, но это намерение было быстро отброшено, как и название FORTRAN VI. Вплоть до 1965 года этот язык был из¬вестен как NPL, что являлось аббревиатурой названия New Programming Language (новый язык программирования). Первый опубликованный отчет о языке NPL был пре¬доставлен на собрании группы SHARE в марте 1964 года. Более полное описание после¬довало в апреле, а работоспособная версия была опубликована в декабре 1964 года (IBM, 1964) группой разработчиков компилятора из выбранной для реализации лаборатории IBM Hursley Laboratory в Великобритании. В 1965 году, чтобы избежать путаницы с аб¬бревиатурой Национальной физической лаборатории (NPL— National Physical Laboratory) в Великобритании, название языка было изменено на PL/I. Если бы компиля¬тор разрабатывался за пределами Соединенного Королевства, название, вероятно, оста¬лось бы прежним."

...окончание...
"Обзор языка PL/I
Возможно, лучшим описанием языка PL/I, состоящим из одного предложения, будет следующее: он содержит то, что считалось лучшими частями языка ALGOL 60 (рекурсия и блочная структура), языка FORTRAN IV (раздельная компиляция со связью посредст¬вом глобальных данных) и языка COBOL 60 (структуры данных, средства ввода-вывода и генерации отчетов), а также несколько новых конструкций, каким-то образом соеди¬ненных в единое целое. Мы не будем пытаться даже в конспективной форме описать все свойства этого языка или хотя бы его наиболее противоречивые конструкции. Вместо этого мы кратко назовем несколько вкладов, сделанных этим языком в фонд знаний в области языков программирования.
Язык PL/I был первым языком, имевшим следующие возможности.
■ Программы могли порождать параллельно выполняемые задачи. Хотя сама идея
была хороша, но ее реализация в языке PL/I была скверной.
■ Появилась возможность выявления и обработки 23 видов различных исключи¬
тельных ситуаций или ошибок в процессе выполнения.
■ Процедуры могли использоваться рекурсивно, но для более эффективного програм¬
мирования нерекурсивных процедур эта возможность могла быть заблокирована.
■ В качестве типа данных были включены указатели.
■ Появилась возможность обращаться к пересекающимся разделам массивов. На¬
пример, к третьей строке матрицы можно было обращаться как к вектору."

...продолжение...
"Оценка
Любая оценка языка PL/I должна начинаться с упоминания о претенциозности работ по его созданию. Оглядываясь назад, кажется наивным полагать, что такое количество конструкций можно было успешно объединить вместе. Тем не менее, это суждение сле¬дует смягчить признанием того, что опыт разработки языков в то время был очень не¬большим. Вообще говоря, структура языка PL/I была основана на допущении, что любая полезная конструкция, которая может быть реализована, должна включаться в язык, при этом вопросу, как большое количество функций сможет ужиться вместе, уделялось мало внимания. Эдсгер Дийкстра (Edsger Dijkstra) в своей лекции на церемонии вручения премии Тьюринга (Turing Award Lecture (Dijkstra, 1972)) подверг сильнейшей критике сложность языка PL/I: "Я совершенно не вижу, как мы можем охватить умом наши уве¬личивающиеся в размере программы, в то время как из-за своей явной переусложненно¬сти язык программирования — наш основной инструмент, прошу отметить! — уже вы¬ходит из-под нашего интеллектуального контроля".
Помимо сложности, возникшей из-за большого размера, язык PL/I страдал от боль¬шого количества конструкций, которые сейчас считаются неудачно разработанными. Среди них можно отметить указатели, обработку исключительных ситуаций, параллель¬ность, хотя мы должны обратить внимание и на то, что в каждой из указанных конструк¬ций было что-то новое.
С точки зрения использования язык PL/I должен считаться, по крайней мере частич¬но, успешным. В 1970-х годах он в значительной мере использовался как в коммерции, так и в науке. В это же время он широко использовался в качестве учебного средства, главным образом в несколько сокращенных формах, таких как язык PL/C (Cornell, 1977) и язык PL/CS (Conway and Constable, 1976)."
...окончание следует...

> Alex Konshin © (03.12.04 21:50) [77]
> Игорь Шевченко © (03.12.04 22:48) [78]

Для своего времени, состояния развития вычислительной техники и программирования PL/I был лучшим.

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

Коррекность или некоррекность в зависимости от контекста - что-то не припомню.

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

А оборудование и ОС были достачно причудливыми, только для дисков существовало несколько методов доступа: 2 последовательных обычных (с очередями и без) плюс 1 управляемый списком (реализован в библиотеке языка), 3 прямых (один с относительной адресацией и два с ключами) и 1 библиотечный. А были еще телекоммуникационный (TCAM), графический (GAM)...
Отсюда громоздкий компилятор и зависимость от платформы. В то время это было обычным явлением, т.к. не было стандартного оборудования. А практика требовала быстрой разработки ПО.

Что касается Алгола - он больше подходил для описания алгоритмов, а не для решения практических задач. На нем, к примеру невозможно разработать систему резервирования билетов или информационную систему для издательства.

Благодаря тому, что Ритчи и Вирт уловили потребность программистов в абстрагировании от оборудования, а также благодаря общему прогрессу средств ВТ и ОС, программисты получили два новых замечательных языка.

Но снова обратимся к PL/I. Мысленно выбросим из него все зависимые от оборудования вещи, отбросим все ОС-зависимые навороты (мультизадачность, события и т.п.). Что останется в итоге? Мы получим язык более защищенный, мощный и эффективный, чем C, имеющий синтаксис близкий к Паскалю. Кому он может не понравиться? При этом необходимо учесть что появился он значительно раньше.

Таким образом, ядро проекта было проработано изумительно.
Основные конструкции языков того времени (FORTRAN, COBOL и Algol) имели близкие аналоги, благодаря чему миграция на этот языт была предельно простой. При этом никаких противоречий в ядре языка не было и в помине. Эффективность генерируемого кода просто потрясала. Оставалось только отделить ядро языка от шелухи.

По каким-то причинам в то время IBM не смогла увидеть этого или не захотела сделать это и дать языку вторую жизнь. А жаль. Здесь я соглашусь с Эндрю Таненбаум: "Наличие четкого представления о своих целях является решающим."

...окончание...
"пример программы на языке PL/I.
/*ПРИМЕР ПРОГРАММЫ НА ЯЗЫКЕ PL/I

ВВОД: ЦЕЛОЕ ЧИСЛО LISTLEN, МЕНЬШЕ 100, ЗА КОТОРЫМ СЛЕДУЕТ
НАБОР ЦЕЛЫХ ЧИСЕЛ В КОЛИЧЕСТВЕ LISTLEN "

ВЫВОД: КОЛИЧЕСТВО ВВЕДЕННЫХ ВЕЛИЧИН, КОТОРЫЕ БОЛЬШЕ ИХ
СРЕДНЕГО АРИФМЕТИЧЕСКОГО
*/
PLIEX: PROCEDURE OPTIONS (MAIN); DECLARE INTLIST (1:99) FIXED. DECLARE (LISTLEN, COUNTER, SUM, AVERAGE, RESULT) FIXED; SUM = 0; RESULT = 0; GET LIST(LISTLEN); IF (LISTLEN > 0) & (LISTLEN < 100) THEN DO; /* СЧИТЫВАНИЕ ВХОДНЫХ ДАННЫХ В МАССИВ И ВЫЧИСЛЕНИЕ ИХ СУММЫ */ DO COUNTER = 1 ТО LISTLEN; GET LIST (INTLIST (COUNTER)); SUM = SUM + INTLIST (COUNTER); END; /* ВЫЧИСЛЕНИЕ СРЕДНЕГО */ AVERAGE = SUM / LISTLEN; /* ПОДСЧЕТ ЧИСЛА ВЕЛИЧИН, КОТОРЫЕ БОЛЬШЕ СРЕДНЕГО */ DO COUNTER = 1 TО LISTLEN; IF INTLIST (COUNTER) > AVERAGE THEN RESULT = RESULT +1; END; /* ВЫВОД РЕЗУЛЬТАТОВ */ PUT SKIP LIST ("ЧИСЛО ВЕЛИЧИН, КОТОРЫЕ БОЛЬШЕ СРЕДНЕГО:"); PUT LIST (RESULT); END; ELSE PUT SKIP LIST ("ОШИБКА - ВВЕДЕНА НЕВЕРНАЯ ДЛИНА СПИСКА"); END PLIEX"
Роберт У. Себеста "Основные концепции языков программирования", из. Вильямс, 2001.

Sha © (04.12.04 00:26) [84]

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

Ну здравствуйте :) Оборудование выпускалось фирмой IBM же, и уж стандартнее его не было на тот момент.

> Для своего времени, состояния развития вычислительной техники
> и программирования PL/I был лучшим.

Я бы не стал так категорично утверждать. Большинство программ все-таки писалось на Коболе и Фортране :)

> Игорь Шевченко © (04.12.04 00:37) [86]

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

> Ну здравствуйте :) Оборудование выпускалось фирмой IBM же, и уж
> стандартнее его не было на тот момент.

Так я про зависимость от платформы.
А ты про что?
Или считаешь, что все фирмы в то время придерживались стандартов IBM?

> Игорь Шевченко © (04.12.04 00:37) [86]

>> Для своего времени, состояния развития вычислительной техники
>> и программирования PL/I был лучшим.

> Я бы не стал так категорично утверждать. Большинство программ > все-таки писалось на Коболе и Фортране :)

Так было до появления PL/I.
Потом ситуация стала исправляться :)
Особенно в Союзе, где из-за задержки с выходом EC некоторые так и не успели попрактиковаться на Коболе.

> Sha © (04.12.04 00:26) [84]
Все это время мучительно вспоминал 8-ой способ обмена данными.
Оказывается, забыл про слона: плюс 1 последовательный форматный (реализован в библиотеке языка).

Sha © (04.12.04 00:57) [88]

> А были еще телекоммуникационный (TCAM),

Саша, насколько я помню, TCAM не поддерживался PL/1

> Или считаешь, что все фирмы в то время придерживались стандартов
> IBM?

А если не затруднит - на каких платформах компилятор PL/1 имел широкое распространение, кроме IBM ?

Насколько мне помнится, из широко распространенных платформа тогда были IBM и DEC - на DEC"овской платформе был PL/1 ? (Я просто не в курсе).

> Так было до появления PL/I.
> Потом ситуация стала исправляться :)
> Особенно в Союзе, где из-за задержки с выходом EC некоторые
> так и не успели попрактиковаться на Коболе.

В Союзе, насколько мне помнится, PL/1 был распространен там же, где сейчас Паскаль (рискну сделать такое утверждение) :)

> Игорь Шевченко © (04.12.04 10:14) [90]

> Саша, насколько я помню, TCAM не поддерживался PL/1

Да, естественно. Это сказано мной в смысле разнообразия аппаратного и программного обеспечения. ТСAM, GAM и, кажется, ISAM не поддерживались непосредственно в языке. Но это легко поправимо благодаря наличию интерфейсов с всеми языками программирования. В часности, для обеспечения доступа пользователей с терминалов EC-7066 и EC-7220 к моей базе был написан переходник на ассемблере по образу и подобию популярных в то время редакторов PRIMUS и JEC.
Насчет ISAM полностью не уверен, т.к. в то время, когда я писал базы на BDAM, знакомые, тоже используя PL/I, писали их на ISAM.

> А если не затруднит - на каких платформах компилятор PL/1 имел
> широкое распространение, кроме IBM ?

Думаю, что еще только на ЕС :)
Была еще пародия на PL/I, сделанная третьей фирмой, на платформе IBM PC.

> Насколько мне помнится, из широко распространенных платформа
> тогда были IBM и DEC - на DEC"овской платформе был PL/1 ? (Я
> просто не в курсе).

Насколько я знаю, нет, не был.

> В Союзе, насколько мне помнится, PL/1 был распространен там
> же, где сейчас Паскаль (рискну сделать такое утверждение) :)

В точку. Именно потому, что свято место пусто не бывает :)
Король умер, да здравствует король!

Sha © (04.12.04 18:07) [91]

> Но это легко поправимо благодаря наличию интерфейсов с всеми
> языками программирования.

Точнее, только с ассемблером :) Насколько мне помнится, попытка связать его с фортраном была несколько трудоемкой.

> по образу и подобию популярных в то время редакторов PRIMUS
> и JEC.

Не трави душу :) И вода тогда была мокрее, и небо голубее, и в водке градус был правильный :))

С уважением,

> Игорь Шевченко © (04.12.04 18:41) [92]

> Точнее, только с ассемблером :) Насколько мне помнится,
> попытка связать его с фортраном была несколько трудоемкой.

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

С оптимизирующим Фортраном у соседей вроде получалось связать оптимизирующий PL/I. Сам не пробовал, но помнится, в сопроводительной документации на PL/I приведено описание связи по данным и по управлению.

> Не трави душу :) И вода тогда была мокрее, и небо голубее, и в
> водке градус был правильный :))

> С уважением,

Это точно.

С уважением.

> Sha © (04.12.04 19:52) [93]

> Например, работать с устройствами ввода/вывода перфоленты
> можно было непосредственно из языка, но только через ассемблер
> удавалось получить полный контроль.

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

Насчет связи с Фортраном - сам делал, без проблем. Там богатая библиотека численных методов была, вот я ее и подцеплял, на уровне объектных файлов.

PL/1 - Programming Language One Найти похожие ветки