БУДЬ ЛАСКА ПОВЕРНІТЬ
Командер Грейс М. Гоппер, Військово-морський резерв США

Доповідь буде представлена Е. Дж. Альбертсоном, Консультантом, Відділ планування методів, на Симпозіумі з комп’ютерних застосувань, організованому Дослідницькою фундацією Армора при Іллінойському технологічному інституті, у місті Чикаго, штат Іллінойс, 28 жовтня 1959 року.

Хоч назва цієї доповіді може бути витлумачена як всебічний огляд усіх сучасних досягнень у галузі програмування універсальною мовою для систем обробки ділових даних, дозвольте запевнити присутніх, що такого завдання вона не ставить.

Насамперед слід зазначити, що мені не відомі всі сучасні розробки у цій галузі. Та навіть якби це було так, то за відведений для доповіді час я могла б лише перелічити їх.

Проте існує одна сучасна розробка, на розгляді якої хотілося б зупинитися. Йдеться про роботу Комітету з мов для систем обробки даних (Committee on Data Systems Languages), утвореного внаслідок конференції представників організацій-користувачів та фірм-виробників обчислювальної техніки, що відбулася в Міністерстві оборони США у травні поточного року.

На початку цього огляду доцільно подати стислий виклад вимог до універсальної мови програмування з погляду користувача систем обробки ділових даних. Складається враження, що всі, за винятком самого користувача, знають, які саме вимоги він висуває до мови програмування. Нерідко користувачам закидають, що вони не можуть чітко сформулювати свої вимоги. Проте є підстави вважати, що вони добре знають, чого потребують, але їм пояснюють, що реалізувати ці вимоги неможливо.

Я не беру на себе сміливості висловлюватися від імені всіх користувачів систем обробки ділових даних, а лише від імені тієї їх частини, яка вважає, що знає свої потреби, і готова сприяти їх задоволенню. Зрозуміло, що поняття «користувач» є досить широким і, більше того, надто узагальненим. Для цілей цієї доповіді під користувачем слід розуміти особу або підрозділ, наділені повноваженнями приймати рішення щодо використання обчислювальної машини та відповідальні за результати її застосування. Виконання цих повноважень і відповідальності, як правило, делегується працівникам штабних і лінійних служб управління, які спеціалізуються на застосуванні обчислювальної техніки. Саме на цьому рівні делегування глибоке знання технічних деталей і постійний тиск невідкладних поточних завдань породжують переконання, що керівництво не може отримати того, чого воно прагне.

Багато причин та пояснень можна привести на підтвердження такого переконання, але мало рішень запропоновано. Кори рішення запропоновано, воно часто критикується тому що воно далеко від ідеалу, або що воно шокує почуття експерта.

Ця ситуація схожа на ту, що виникла в організаціях зі збуту наприкінці періоду ринку продавця кілька років тому, коли приймачі замовлень зіткнулися з необхідністю використовувати навички переконання, щоб продавати свою продукцію. Саме ця необхідність стала тим поштовхом, який перетворив приймачів замовлень на продавців.

Організації, що займаються системами даних (Data systems organisations), опинилися в подібній ситуації: пояснення й виправдання більше не сприймаються, а глибоке знання деталей і нагальних проблем має стати стимулом до пошуку ефективних рішень.

Поки що я говорив, що керівництво знає, чого воно хоче, і припускав, що воно хоче спільної мови програмування. Що ж таке спільна мова програмування і чому керівництво цього хоче?

Я вважаю, що на друге запитання слід відповісти спочатку, оскільки потреба зазвичай передує бажанню. Потреба виникає через ситуацію, в якій опиняється користувач невдовзі після того, як стає щасливим власником комп’ютера, і метушливо грається пальцями, очікуючи на обіцяні переваги, які, згідно з дослідженнями доцільності, він мав би отримати. Очікування поступово переростає в роздратування, а потім — у прагнення діяти.

Дослідження ситуації показує, що витрати стрімко накопичуються, а переробка прикладних програм на комп’ютер значно відстає від графіка. Як причини або виправдання називають те, що програмування займає більше часу, ніж очікувалося, а комп’ютер працює з несправностями. Скарги виробникові комп’ютера зазвичай призводять до усунення технічних несправностей машини. Проте, схоже, немає іншого способу скоротити затримки в програмуванні, окрім як найняти більше програмістів. Це роблять, але ситуація не покращується. Подальше дослідження виявляє, що внесення змін до вже завершених програм стало важливою складовою загального обсягу робіт із програмування. Коли виникає питання, чому потрібні ці зміни, з’ясовується, що з’явилися нові або змінені умови обробки даних через зміни в бізнес-вимогах. Крім того, тепер доступні нові й досконаліші комп’ютери, використання яких необхідне для задоволення нових потреб. Отже, програми доводиться переглядати. Більше того, накопичений досвід відкрив шлях до багатьох нових застосувань, які спочатку навіть не розглядалися. У тих випадках, коли комп’ютери використовуються в кількох географічно віддалених місцях, виявляється, що однакові або дуже схожі прикладні програми розробляються незалежно в кожному з них.

Аналіз загальної ситуації показує, що потрібне рішення саме в галузі програмування. Збільшення кількості програмістів не може розв’язати проблему, оскільки, схоже, існує межа кількості людей, яких можна ефективно залучити до кожного окремого проєкту. Рішення, здається, полягає в тому, щоб кожен програміст створював більше програмного забезпечення. Однак з’ясовується, що цього неможливо досягти без ширшого використання засобів автоматичного програмування. І коли починають шукати способи розширити застосування автоматичного програмування, виявляється, що попереду чекає зовсім нова проблема.

Ця нова проблема має кілька аспектів. Автоматичне програмування, схоже, доступне в багатьох формах. Кожен виробник пропонує власні засоби автоматичного програмування для своїх комп’ютерів. Деякі пропонують окремі пакети автоматичного програмування для кожного типу комп’ютерів, які вони випускають, а в окремих випадках — навіть кілька варіантів для однієї й тієї самої машини. У розробці цих різноманітних методів проявлено значну винахідливість, а ще більше творчості, здається, було вкладено у надання їм екзотичних і таких, що вселяють довіру, назв.

Загалом переваги наявних методів автоматичного програмування полягають у такому:

  • Скорочення часу, необхідного для початкового програмування.
  • Скорочення часу, необхідного для тестування програм.
  • Скорочення часу, необхідного для внесення змін до наявних програм у відповідь на зміну вимог до обробки інформації.
  • Скорочення часу, необхідного для підготовки програмістів.
  • Ширше залучення фахівців, які добре знають інформаційні потреби бізнесу, але не знайомі з технологією програмування комп’ютерів.

Однак використання наявних методів автоматичного програмування має й низку недоліків:

  • Спеціалізоване призначення, тобто обмежена придатність лише для невеликого класу застосувань.
  • Обмежені можливості в тому сенсі, що метод не здатний програмувати складні задачі без повернення до програмування складною мовою самої машини.
  • Збільшення часу роботи комп’ютера, необхідного для компіляції об’єктної (виконуваної) або обробної програми.
  • Збільшення часу роботи комп’ютера, необхідного для обробки даних за допомогою об’єктної або обробної програми.
  • Небажання деяких досвідчених програмістів використовувати методи автоматичного програмування.

Звісно, існують й інші переваги та недоліки, але вони мають порівняно менше значення. Сукупний вплив перелічених переваг і недоліків створює суттєву перевагу на користь наявних засобів автоматичного програмування. Користувачі загалом це усвідомлюють і вже користуються цими перевагами.

Проте наявні засоби автоматичного програмування не задовольняють потреб користувачів і розв’язують їхні проблеми лише незначною мірою.

Ці потреби можна чітко визначити й задовольнити. Як я вже зазначав раніше, моя мета полягає в тому, щоб визначити ці вимоги з погляду того, чого хоче користувач і чому він цього хоче, а потім пов’язати їх із роботою Комітету з мов для систем обробки даних.

Користувач прагне розв’язати проблему надмірних грошових і часових витрат на програмування, а також усунути витрати, пов’язані з перепрограмуванням. Він хоче цього, щоб досягти своєї головної мети — забезпечити ефективніше функціонування свого бізнесу.

Розв’язання проблеми надмірних часових і фінансових витрат на програмування потребує спільної мови для написання програм обробки даних для електронних комп’ютерів.

Вимоги до такої спільної мови полягають у тому, щоб вона була:

Незалежною — мова повинна давати змогу описувати процедуру обробки даних у термінах самої задачі, а не в термінах конкретного комп’ютера.

Простою — мова має складатися з простих англійських слів і речень.

Трансльованою — має існувати автоматичний (машинний) спосіб перекладу спільної мови мовою всіх сучасних і майбутніх комп’ютерів.

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

Придатною до переписування — зміни до програми, спочатку написаної цією спільною мовою, повинні вноситися саме цією спільною мовою, а не мовою машини.

Придатною до тестування — має існувати автоматичний (машинний) спосіб перевірки логіки й арифметики процедур обробки даних, написаних цією мовою.

Одним із важливих аспектів розробки спільної мови для бізнесу є те, що вона приносить користь як користувачам, так і виробникам.

Користувач зможе запускати свої прикладні програми на тих комп’ютерах, які він сам обере, причому з такими витратами часу й коштів, що відповідатимуть його потребам.

У результаті зростатиме обсяг прикладних програм, які виконуються на комп’ютерах, а виробники отримають значно ширший ринок. Крім того, і користувачі, і виробники зможуть впроваджувати нове, удосконалене обладнання одразу після його появи, а старіші комп’ютери зможуть використовуватися новими користувачами без занепокоєння щодо часових і фінансових витрат на подальшу модернізацію обладнання.

Тепер уже визначено, чого хоче користувач (спільної мови програмування), чому він цього хоче (щоб мати змогу використовувати комп’ютери для ефективнішого ведення свого бізнесу), а також сформульовано характеристики й вимоги до цієї спільної мови.

Залишається проблема: як отримати таку мову. Спроби в цьому напрямі вже робилися, але вони завершувалися невдачею, затримками або небажаними компромісами.

Здається, існують два загальні підходи. Перший — законодавче врегулювання, яке потребувало б надто багато часу й було б складним для впровадження. Другий — добровільна домовленість і співпраця між користувачами та виробниками електронних комп’ютерів.

Другий підхід видається більш бажаним і практичним. Робота в цьому напрямі вже ведеться, і зараз я хотів би розглянути одну з найважливіших ініціатив у цій сфері — ту, яка, на мою думку, має всі шанси на успіх у найближчому майбутньому. Йдеться про діяльність Комітету з мов для систем обробки даних.

Комітет з мов для систем обробки даних було створено внаслідок пропозиції, щоб Міністерство оборони США об’єднало користувачів і виробників для розроблення специфікацій спільної бізнес-мови для автоматичного програмування систем обробки даних. Цю пропозицію висунула група, до складу якої входили представники користувачів, виробників і університетів. Вони зібралися 8 квітня 1959 року в Обчислювальному центрі Пенсильванського університету, щоб обговорити проблему створення спільної бізнес-мови.

У відповідь на цю пропозицію Дослідницький підрозділ із систем обробки даних при Офісі помічника міністра оборони запросив представників користувачів і виробників на зустріч, що відбулася в Пентагоні 28–29 травня 1959 року, для розгляду питання розроблення специфікацій спільної бізнес-мови для автоматичного програмування цифрових комп’ютерів.

Було неможливо запросити на зустріч 28–29 травня всіх осіб і організації, які добровільно могли б узяти участь і мали безпосередній інтерес або достатню компетентність у цій проблемі. Проте участь і допомога в цьому проєкті вітаються з боку всіх таких осіб і організацій, а результати роботи Комітету планується зробити доступними для всіх.

Було досягнуто згоди щодо того, що спільна бізнес-мова є необхідною і що її створення є можливим та практично здійсненним. Також було визнано складність розроблення такої мови та досягнення її загального визнання. Водночас існує переконання, що ця мова повинна бути внутрішньо простою за своєю структурою й забезпечувати точне передавання інформації між людьми та машинами.

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

Перший етап розроблення полягає у створенні спільної бізнес-мови, орієнтованої на задачі й незалежної від конкретного комп’ютера. Це означає, що мовою можна буде описувати процедури обробки даних для задач, які виконуватимуться на комп’ютері, використовуючи спільну для всіх комп’ютерів мову. Водночас ця мова буде орієнтована насамперед на програмістів.

Другий етап розроблення полягає в розвитку цієї спільної бізнес-мови до такого рівня, щоб вона стала орієнтованою на системи й незалежною від конкретного комп’ютера. Це означає, що мовою можна буде визначати процедури обробки даних незалежно від особливостей функціонування комп’ютера, а сама вона буде наближена до традиційного способу опису бізнес-процедур.

Третій етап передбачає дослідження фундаментальних принципів і філософії мов для систем обробки даних із довгостроковою метою створення мови, яка поєднуватиме вимоги бізнес-мови з вимогами наукової мови.

Можливо, доречно буде сказати кілька слів про склад Комітету з мов для систем обробки даних. До його складу входять представники 26 великих організацій-користувачів і 10 провідних виробників комп’ютерів загального призначення. Представники цих користувачів і виробників мають значний досвід використання комп’ютерів і погодилися спільно розробити та впровадити спільну мову для програмування прикладних систем обробки бізнес-даних.

Група короткострокового напряму складається з представників трьох організацій-користувачів і шести виробників. Її завдання полягає в розробленні першого етапу спільної мови для програмування бізнес-застосувань на цифрових комп’ютерах. Цей етап розвитку мови визначено як «орієнтований на задачі й незалежний від машини». Це означає, що мовою можна описувати процедури обробки даних для задачі, яка виконуватиметься на комп’ютері, але використовувати при цьому мову, спільну для всіх комп’ютерів. Цей етап розроблення відрізняється від наступних тим, що користувач мови повинен мати елементарні знання з програмування комп’ютерів. На подальших етапах розвитку ця вимога буде усунута без зміни самої мови.

Запланованою датою завершення першого етапу було визначено грудень 1959 року. Цільові терміни завершення другого й третього етапів на той момент ще перебували на стадії обговорення. Проте слід пам’ятати, що йдеться лише про одну мову. Три групи працюють над різними етапами розвитку єдиної спільної бізнес-мови.

З цілком очевидних причин робота над першим етапом просунулася значно далі, ніж над другим і третім. Роботу над першим етапом було розпочато набагато раніше, тоді як наступні етапи мусили чекати на вироблення фундаментальних принципів у межах першого. Саме тому я зосереджуся переважно на досягненнях першого етапу, оскільки саме там вдалося досягти найбільших результатів.

Результати роботи на першому етапі були такими. Було проведено дослідження практики використання засобів автоматичного програмування, щоб визначити реальний досвід кількох організацій-користувачів. Результати цього дослідження стали для групи корисним орієнтиром під час планування подальшої роботи. До опитування були залучені користувачі зі сфер освіти, промислового виробництва, державного управління та страхування, які використовували вісім різних мов автоматичного програмування.

Серед цих організацій частка програм, написаних мовами автоматичного програмування, коливалася від 10 до 85 відсотків. Програми, створені такими мовами, становили від 30 до 100 відсотків усього машинного коду.

Було встановлено, що групи, які займалися розробленням систем поза сферою електронної обробки даних (EDP), лише зрідка брали участь у проєктуванні систем і програмуванні комп’ютерів.

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

Учасники дослідження дійшли спільної думки, що для підготовки нового програміста до ефективної роботи з мовою автоматичного програмування потрібно приблизно два тижні, тоді як для програмування мовою машини — близько двох місяців.

Основними перевагами систем автоматичного програмування було названо скорочення часу, необхідного для написання програм, їх тестування, налагодження, внесення змін під час супроводу та навчання програмістів.

Якість об’єктних (виконуваних) програм оцінювалася як така, що становить приблизно від 80 до 90 відсотків ефективності програм, написаних мовою машини.

До застосувань, що програмувалися за допомогою систем автоматичного програмування, належали: розрахунок заробітної плати, статистика продажів, облік собівартості продукції, ощадні фонди, пенсійні програми, виставлення страхових рахунків, управління запасами та управління виробництвом.

За результатами дослідження було зроблено висновок, що автоматичне програмування, хоча й перебуває ще на ранньому етапі свого розвитку, є кращим за програмування мовою машини. Також було встановлено, що існує потреба в удосконалених засобах автоматичного програмування, заснованих на спільній бізнес-мові, і що їх цілком можливо створити.

Після цього робота перейшла до вивчення наявних мов автоматичного програмування, які використовували організації, охоплені дослідженням.

Від самого початку було очевидно, що застосовувані методи й технічні підходи суттєво відрізнялися між собою та відображали специфічні вимоги тих комп’ютерів, для яких вони були розроблені. Узгодження цих відмінностей фактично означало б узгодження відмінностей між самими комп’ютерами. Це, безперечно, було б надзвичайно складним, якщо взагалі можливим, завданням. Водночас було встановлено, що фундаментальні передумови для створення спільної мови вже існують, а завдання полягає в тому, щоб розробити мову, яка поєднає найкращі риси всіх досліджених мов.

Однією зі сфер, що потребували ґрунтовного дослідження, було питання опису даних і опису файлів. Було встановлено, що дані, які підлягають обробці, поділяються на три категорії: по-перше, дані, що містяться у файлах і завантажуються до внутрішньої пам’яті комп’ютера та вивантажуються з неї через визначені області; по-друге, константи, які використовуються програмою і повинні бути задані; по-третє, дані, що формуються всередині системи й розміщуються у спеціально відведеній проміжній робочій області пам’яті. Таблиці можуть належати до будь-якої з цих трьох категорій залежно від способу їх використання. Найчастіше вирішальним чинником є розмір таблиці.

Користувачі систем електронної обробки даних давно усвідомили, що одним із головних джерел помилок у програмуванні є операції введення й виведення файлів, особливо тоді, коли вихідні дані однієї процедури використовуються як вхідні дані для іншої. Проблеми, що виникають унаслідок внесення змін до файлу, є складними й потребують значних витрат часу та коштів. Бажано мати можливість вносити зміну лише в одному місці, щоб вона автоматично відображалася в усіх процедурах, яких вона стосується.

Ще однією вимогою користувачів є можливість зберігати в одному файлі процедури, визначені за допомогою операторів процедур, описів даних і характеристик середовища, та використовувати їх на кількох різних комп’ютерних системах без необхідності або майже без необхідності переписувати ці описи вручну. Подальшим розвитком цієї ідеї є вимога, щоб уся система була відкритою до розширення, тобто могла вільно розвиватися й доповнюватися.

Ще одна важлива вимога полягає в тому, щоб описи даних були зрозумілими користувачеві. Водночас вважається, що такі описи повинні розроблятися й документуватися програмістом найвищого рівня, який добре розуміє саму задачу, носій, на якому дані зберігаються й з якого вони зчитуються, а також внутрішню будову комп’ютерних систем, на яких виконуватиметься ця задача.

Обраний підхід полягає в розмежуванні тієї частини файлу, процедури обробки якої орієнтовані на користувача, і тієї частини, процедури обробки якої можуть бути однаково визначені для різних комп’ютерних систем. Ці дві частини називаються відповідно описом файлу та детальним описом даних. Визнано, що для одного й того самого детального опису даних жодні дві системи компіляції не обов’язково оброблятимуть інформацію однаково, так само як і різні комп’ютерні системи, ймовірно, не вимагатимуть однакового мінімального обсягу інформації. Однак детальний опис даних визначено таким чином, щоб він містив як універсально необхідну інформацію, так і додаткові відомості, потрібні для конкретної системи або групи систем, для яких призначено відповідну задачу.

Форма подання цієї інформації фактично є вільною, причому найважливішим є порядок розташування відомостей. Слід зазначити, що за цими правилами жоден конкретний користувач або виробник не зобов’язаний використовувати вільний формат як вхідні дані. Водночас система компіляції повинна формувати вихідний опис саме у вільному форматі, який використовуватиметься як спільний засіб обміну між різними комп’ютерними системами, а також як один із необхідних елементів повного звіту з аналізу системи (complete system analysis report) користувача. Варто підкреслити, що вільний формат забезпечує гнучкість під час перенесення програм між різними комп’ютерними системами, а також реалізує необхідну відкритість системи до подальшого розвитку.

Передбачається, що описи файлів і детальні описи даних зберігатимуться на бібліотечній магнітній стрічці й викликатимуться за потреби, подібно до того, як використовуються бібліотеки підпрограм. Водночас передбачено можливість включати опис файлу безпосередньо до складу програми, так само як у програмі визначаються константи та додаткова робоча пам’ять. Ще одним питанням, яке потребувало уваги, було визначення загальних принципів побудови мови операторів, переліку дієслів і формату їх використання.

Загальні принципи побудови мови операторів встановили чіткі правила щодо набору символів, які можуть використовуватися, правил утворення та вживання слів, а також правил формування операторів.

Загалом було визначено 23 дієслова для виконання арифметичних операцій, операцій введення-виведення, перевірок і передавання керування, переміщення даних, завершення виконання, а також спеціальних директив для компілятора.

Формат використання цих дієслів визначав нотацію, яка застосовувалася для їх опису, а також правила формулювання визначень, що пояснювали призначення кожного дієслова. Оскільки метою мого огляду не є пояснення принципів роботи спільної бізнес-мови, розробленої цією групою, а також не є обґрунтування доцільності її використання, я не вдаватимуся до подробиць її побудови чи застосування. Детальний розгляд цього аспекту буде представлено після публікації завершеного опису мови, який очікується наступного місяця.

Головне, що я хочу підкреслити зараз, полягає в тому, що група, до складу якої входять представники десяти провідних виробників комп’ютерів загального призначення та двадцяти шести великих організацій-користувачів, спільно працювала над досягненням єдиної взаємовигідної мети й погодилася разом працювати над її практичним втіленням.

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

Ще раз слід наголосити, що два наступні етапи передбачають подальший розвиток тієї самої мови, а не створення нової.

Можливо, це стане зрозумілішим, якщо коротко розглянути роботу, яку ще належить виконати на етапах, покликаних зробити мову зручнішою у використанні, орієнтувати її на опис систем і забезпечити її незалежність від конкретного комп’ютера.

Для цього необхідно дослідити природні мови та способи їх використання в людському спілкуванні з метою виявлення, відкриття або формулювання фундаментальних принципів людських мов. Після цього необхідно дослідити принципи мов, що використовуються для взаємодії між машинами. На цьому етапі вважається, що принципи взаємодії між людьми й машинами можна спростити настільки, щоб стало можливим описувати задачі та їх розв’язання мовою, наближеною до традиційного способу запису бізнес-процедур.

Це є надмірно спрощеним описом завдання, яке необхідно виконати, але він не має на меті бути узагальненням. Робота над другим етапом уже перебуває на попередній стадії.

Першим кроком на цьому етапі є створення функціональної мови для вираження бізнес-задач у процедурній формі, а другим кроком — вирішення питання реалізації цієї мови для комп’ютерів зі збереженою програмою.

Було досягнуто значного прогресу в огляді сфер, які потребують попереднього дослідження. Зокрема, дві робочі групи окремо займаються фундаментальними питаннями структури мови та бізнес-задачами. Робочій групі з питань структури мови доручено дослідити й розробити структуру мови проміжного етапу, визначити її синтаксис і, зрештою, наповнити мову словами, словосполученнями, реченнями, абзацами тощо.

Було погоджено, що на початкових етапах розроблення конкретна проблема реалізації мови для комп’ютерів зі збереженою програмою не повинна бути визначальною. Натомість головною має бути здатність мови описувати бізнес-системи. Було погоджено, що під описом бізнес-систем обробки даних мається на увазі формулювання процедур, які становлять цю систему; тобто оператори необхідної мови будуть процедурними операторами. Також було погоджено, що після того, як структура мови буде чітко визначена, буде розглянуто проблему реалізації мови для комп’ютерів зі збереженою програмою та вжито необхідних заходів для її впровадження.

Робочій групі з опису бізнес-задач було доручено переглянути описи бізнес-систем і процедур та визначити вимоги, яким повинна відповідати запропонована мова. Серед іншого, очікується, що ця робоча група зможе виявити деякі типові процедури, які можна буде узагальнити. У будь-якому разі передбачається, що вона розгляне якомога більше описів бізнес-задач і виокремить інформацію, яка може бути корисною для розроблення мови, а також пропозиції, які можна буде використати для її тестування в процесі розвитку.

На цьому завершується огляд роботи Комітету з мов для систем обробки даних і підсумок погляду користувача щодо вимог до програмування спільною мовою.

Хоча я вважаю, що робота Комітету з мов для систем обробки даних спрямована на задовільне вирішення проблеми програмування і що він досягне цієї мети, я переконаний, що необхідно сформувати широку підтримку та зацікавленість у цьому питанні серед великого кола користувачів і виробників.

З одного боку, прийняття мови, розробленої цим Комітетом, є добровільним для користувачів і виробників. З іншого боку, існує багато інших способів виконання цього завдання. Можливо, ці інші підходи були б більш прийнятними для окремих шкіл думки щодо методів створення мов. Оскільки не існує єдиного керівного органу з цього питання (і я вважаю, що створення такого органу зараз було б складним і небажаним), ці різні альтернативи можуть передбачати компроміси щодо технічних підходів, але не щодо фундаментальних принципів бажаного й досяжного рішення. Користувачі та виробники, які беруть участь у роботі Комітету з мов для систем обробки даних, зараз вирішують незначні розбіжності в поглядах, щоб досягти задовільного й практичного рішення, взаємна користь від якого значно перевищить невеликі коригування позицій, на які вони погоджуються.

Групи, що працюють над цим рішенням, керуються спільною потребою та вкладають час і здібності своїх компаній і власні ресурси в пошук цього рішення. Результати їхньої роботи будуть доступні всім користувачам і виробникам незалежно від того, чи брали вони участь у цій роботі. Намір цих груп полягає в тому, щоб завершити свою роботу якомога швидше. Крім того, вони не мають наміру перетворюватися на постійний орган.

Вони прагнуть залучити й використати всю доступну та запропоновану активну допомогу від компетентних фахівців.

Можливо, доречно буде зробити кілька зауваг щодо цього питання. Слід пам’ятати, що групи, які працюють над цим рішенням, представляють значну частину користувачів і виробників. Проте існує багато інших користувачів і виробників, які мають інтерес і досвід у сфері комп’ютерного програмування. Зацікавленість цих інших користувачів і виробників є необхідною, і їх запрошують до участі, щоб робочі групи могли залучити більше розумів і рук безпосередньо до роботи над кожним етапом.

Можливо, деякі з них захочуть активно брати участь у роботі цих груп. Інші можуть побажати висловити свою зацікавленість і підтримку цього підходу. Оскільки всі матимуть можливість скористатися результатами та перевагами цієї роботи, видається, що кожен має серйозно замислитися над питанням програмування спільною мовою. Цей проєкт потребує конструктивної допомоги від осіб, які мають компетентність у сфері автоматичного програмування та водночас здатні знаходити й упроваджувати способи досягнення поставленої мети. Безперечно, існують й інші способи досягнення цієї мети, але очевидно, що наразі немає такого підходу, який міг би або зміг би отримати схвалення всіх зацікавлених сторін.