PL/1 - Programming Language One

← →
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 и др...
или я не прав?....

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

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

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

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

← →
MOA © (2004-12-02 22:33) [68]

Можно, и мои пять копеек? ;).
Вот в этом, ПМСМ, всё и дело. На ранних стадиях науки "информатика" пытались сделать в языке все основные абстракции. "Список", "Дерево", "Стек", "Очередь" ... Соответственно - обязаны реализовать операции над этими типами данных. И вот тут и трудность - полезные структуры данных множатся + набор "общепринятых" базовых операций может и измениться + запросто могут появится и другие, не менее полезные структуры.
Выход был найден - либо реализацией в языке базовой функциональности с неслабой поддержкой подпрограмм (библиотек, пакетов и т.д.) - 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, а в области системных приложений — еще и язык ассемблера."
...продолжение следует...

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