Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Языки программирования. Концепции и принципы
.pdf
Концептуальная схема языка программирования
лизует вторую из названных способностей – служит для выполнения действий,
предусмотренных в планах. Это активный ресурс. Процессор характеризуется
определенным набором допустимых действий (операций, команд). Действия из
этого набора считаются элементарными (в плане не нужно заботиться о способе
выполнения таких действий).
Две названные способности связаны – выполнение достаточно сложного пла
на требует его хранения в доступной исполнителю памяти. В свою очередь, реали
зация хранения требует способности выполнять план (данные нужно размещать,
перемещать, делать доступными).
План для такого исполнителя, как компьютер, должен в итоге сводиться к ука
занию конечной последовательности элементарных действий. Такой план назы
вают программой.
Людей как исполнителей характеризует прежде всего наличие у них модели ре
ального мира, в достаточной степени согласованной с моделью мира у создателя пла
на. Поэтому в плане для людей можно указывать цели, а не элементарные действия.
Ресурс, существенный почти для всех реальных исполнителей, – это время.
Важное свойство компьютеров как исполнителей – способность выполнять эле
ментарные действия исключительно быстро (порядка микросекунды на дей
ствие). Не менее важное свойство компьютера – способность хранить огромные
объемы данных (в оперативной памяти – мегабайты; на внешней – практически
не ограничено).
Именно способность компьютеров выполнять весьма длинные последователь
ности элементарных действий над данными любого нужного объема за практи
чески приемлемое время предоставляет пользователям весьма разнообразные по
содержанию услуги (развлекать, играя с ним в интеллектуальные и (или) азарт
ные игры, давать справки, помогать в составлении планов, управлять самолетами
и танками, поддерживать светскую беседу).
Чтобы настроить компьютер на конкретный вид услуг, нужно снабдить его со
ответствующими этому виду услуг знаниями в приемлемой для него форме.
Принципиально важный для нас факт, ставший очевидным лишь относительно
недавно (по мере расширения и развития сферы предоставляемых компьютерами
услуг), состоит в том, что самое сложное (и дорогое) в этом деле – не сами компь
ютеры, а именно представление знаний в приемлемой для них форме. В наше вре
мя аппаратура в компьютере по своей относительной стоимости иногда сравнима
с упаковкой, в которую «заворачивают» знания.
Знания, представленные в компьютерах, традиционно называют программами
(таким образом, под программой в широком смысле слова понимают не только
планы). Соотношение стоимости аппаратуры и программ (а также иные сообра
жения) во многих случаях дает основание абстрагироваться от используемой ап
паратуры и говорить об услугах, предоставляемых непосредственно программа
ми, а также о производстве программных услуг.
Подчеркнем, что пока далеко до полной независимости программ от исполь
зуемой аппаратуры. Проблема переноса программ (на исполнитель другого ти
па) – одна из острейших проблем современного программирования. И тем не ме
31

32
нее обычно затраты на создание достаточно сложной программы определяются
в основном сущностью решаемой задачи (предоставляемой услуги), а не исполь
зуемой аппаратуры.
Правомерность абстракции от аппаратуры подчеркивает определенную искус
ственность проблемы переноса программ. Если пока в значительной степени без
различно, на чем программировать, то разнообразие и несовместимость исполни
телей вызваны не объективными, а социальными причинами.
Знания, представляемые в компьютерах, можно разделить на пассивные и ак
тивные. Первые отражают факты, связи и соотношения, касающиеся определен
ного вида услуг. Вторые – это рецепты, планы действий, процедуры, непосред
ственно управляющие исполнителем.
Представление пассивного знания ориентировано в первую очередь на такой
ресурс компьютера, как память, а представление активного – на процессор. Исто
рически самыми первыми сферами применения компьютеров оказались такие,
где главенствовало активное знание – эксплуатировалась способность ЭВМ не
столько много знать, сколько быстро считать.
Кстати, и память на первых ЭВМ была очень мала по сравнению со скоростью
работы процессора. Всю свою память они могли просмотреть (или переписать) за
десятую долю секунды. Недалеко ушли в этом отношении и современные компь
ютеры (если говорить об оперативной памяти).
Соотношение между объемом оперативной памяти и скоростью процессоров
активно влияет на мышление программистов, инженеров, пользователей, а также
всех связанных с компьютерами людей. Изменение этого соотношения (а его ра
зумно ожидать) способно произвести революцию в практическом программиро
вании (см. далее о модифицированной модели Маркова и функциональном стиле
программирования (модель Бэкуса); есть и другие перспективные модели, напри
мер реляционная). Пока же программисты вовсю экономят память, помещая но
вые значения на место старых, а преподаватели учат искусству такого «эффектив
ного» программирования. В «эффективных» программах трудно восстановить
процесс получения результата, трудно объяснить неожиданный результат.
Традиционный стиль программирования, обусловленный бедностью ресурсов,
затрудняет написание, понимание, проверку и удостоверение правильности про
грамм. Тенденция развития состоит в том, что роли активного и пассивного зна
ний в производстве программных услуг становятся более симметричными, а забо
та об эффективности отступает перед заботой о дружественности программы.
Современное состояние языков программирования
1.11. Производство программных
услуг – основная цель
программирования
Измерять эффективность того или иного производства разумно лишь по отноше
нию к его цели (конечному результату). Поэтому важно понимать, что конечная
цель программирования – не создание программ самих по себе, а предоставление

Концептуальная схема языка программирования
программных услуг. Другими словами, программирование в конечном итоге на
целено на обслуживание пользователей. А настоящее обслуживание должно ру
ководствоваться известным принципом: «Клиент всегда прав». В применении
к программированию этот принцип означает, что программы должны быть «дру
жественными» по отношению к пользователю. В частности, они должны быть на
дежными, робастными и «заботливыми».
Первое означает, что в программе должно быть мало ошибок, второе – что она
должна сохранять работоспособность в неблагоприятных условиях эксплуата
ции, третье – что она должна уметь объяснять свои действия, а также ошибки
пользователя.
Что значит «мало ошибок», зависит от назначения программы (ясно, что про
грамма обучения русскому языку и программа автопилота могут иметь различ
ную надежность). Под «неблагоприятными условиями» понимается ограни
ченность выделяемых программе ресурсов (память, каналы вводавывода, число
процессоров), перегрузка (много пользователей, большие объемы данных), ошиб
ки пользователей, сбои и отказы аппаратуры, попытки намеренно вывести про
грамму из строя и т. п.
Сказанное относится к работе программы. Однако важно понимать, что про
граммная услуга – это не только услуга, оказываемая пользователю непосред
ственно при работе компьютера под управлением программы, но и проверка,
оценка, продажа, подбор программ, их перенос на другой исполнитель, сопровож
дение и аттестация (авторитетное подтверждение качества) программ и т. п.
Когда производство программных услуг достигает некоторой степени зрелости,
из кустарного производства вырастает индустрия программных услуг и обслужи
вающая ее потребности теория программирования. Как индустрия, так и кустарное
производство пользуются при этом той или иной технологией – технологией
производства программных услуг, то есть технологией программирования.
(О связи науки, искусства, теории и технологии в программировании см. за
мечательную Тьюринговскую лекцию Дональда Кнута в Communication of the
ACM. – 1974. – Vol. 12. – P. 667–673).
33
1.12. Сложность как основная
проблема программирования
Итак, основная цель программирования – производство программных услуг. Из
вестно, что этот род человеческой деятельности в развитых странах уверенно вы
ходит на первое место среди всех других производств (скажем, в США соответ
ствующая отрасль хозяйства уже опередила недавних лидеров – нефтяную и
автомобильную отрасли).
Вместе с тем известно, что создание программ и предоставление других
связанных с ними услуг остается слишком дорогим и относительно длитель
ным делом, в котором трудно гарантировать высококачественный конечный
результат.

34
В чем же основная причина такого положения? Связана ли она с самой приро
дой программирования или носит субъективный характер?
В настоящее время краткий ответ можно сформулировать так: «сложность –
основная проблема программирования; связана с самой его природой; можно на
деяться на ее понижение для освоенных классов задач».
Современное состояние языков программирования
1.13. Источники сложности
Попытаемся подробнее разобраться с тем, почему же сложность объектов, с кото
рыми приходится иметь дело, – отличительная черта программирования компью
теров. Найдя источники сложности, можно с большей надеждой на успех искать
пути ее преодоления.
Когда исполнители работают медленно, а действия, которые считаются эле
ментарными, специфичны для вида предоставляемых услуг, то планирование
деятельности исполнителя и критерии качества такого планирования существен
но зависят и от услуги, и от конкретного набора элементарных действий.
Вряд ли стоит поручать, скажем, заводскому технологу, специалисту по обра
ботке металлов резанием, планирование индивидуального пошива верхней одеж
ды. Для этого есть закройщики, которые, в свою очередь, вряд ли смогут приме
нить свое искусство при создании заводских технологических карт. Другими
словами, набор «элементарных» действий двух рассмотренных категорий испол
нителей считать эквивалентными неестественно.
Компьютеры работают быстро, и наборы их команд в известном смысле экви
валентны. Причем уже в течение многих лет сохраняется тенденция к увеличе
нию скорости и объема памяти при фиксированной цене (примерно на порядок за
десятилетие). В таких условиях возникает принципиальная возможность настро
ить исполнителя на предоставление услуг из очень широкого класса (во всяком
случае, границы этого класса неизвестны). Для этого достаточно снабдить испол
нителя подходящим планом (написать программу).
Эта принципиальная возможность соблазняет настраивать компьютеры на
виды услуг, очень далеких от элементарных возможностей исполнителя. Более
того, таковы почти все практически значимые услуги. Поэтому в общем случае
план должен предусматривать огромное количество элементарных действий над
огромным количеством элементарных объектов. Но этого мало. Самое главное –
огромное количество связей между этими объектами. Поэтому и сами программы
становятся огромными (уже имеются программы из миллионов команд, напри
мер для управления военными и космическими объектами).
Между тем способности человека работать с большим числом связанных
объектов, как хорошо известно, весьма ограничены. В качестве ориентира при
оценке этих способностей указывают обычно на так называемое «число Ингве»,
равное семи (плюсминус 2). Другими словами, человек обычно не в состоянии
уверенно работать с объектом, в котором более семи компонент с произвольными
взаимными связями. До тех пор, пока программирование остается в основном че
ловеческой деятельностью, с указанным ограничением необходимо считаться.

Концептуальная схема языка программирования
Таким образом, предоставив универсальность, скорость и потенциально не
ограниченную память, создатели компьютеров, с одной стороны, соблазнили че
ловечество неслыханными возможностями, а с другой – поставили лицом к лицу
с проблемами невиданной потенциальной сложности (при попытке осуществить
эти гипотетические возможности).
В этой связи упомянем известный принцип «труд на юзера спихнуть» (user –
пользователь). Изобретатели компьютеров, предоставив в распоряжение про
граммистов исключительное по своим возможностям абстрактное устройство,
«спихнули» на них труд по настройке этого абстрактного устройства на предо
ставление конкретных услуг. Но такая конкретизация оказалась далеко не три
виальной. Программисты, в свою очередь, создавая «универсальные» программы,
«спихивают» труд по их применению в конкретных условиях на потенциальных
пользователей этих программ.
Итак, первый источник сложности в программировании – так называемый
семантический разрыв – разрыв между уровнем и характером элементарных
объектов и операций, с одной стороны, и потенциально возможных услуг – с дру
гой. Иными словами, это проблема согласования масштаба – ювелирными инст
рументами предлагается сооружать города.
Именно этот источник имелся в виду, когда шла речь об объективном характе
ре присущей программированию сложности. Занимаясь определенным классом
услуг (задач), можно стремиться выделить характерный именно для этого класса
набор элементарных объектов и операций, построить соответствующий исполни
тель (аппаратным или программным способом) и программировать на таком бо
лее подходящем исполнителе. Фактически это означает создать адекватный вы
бранному классу услуг ЯП. На практике это самый распространенный способ
борьбы со сложностью и одновременно основная причина роста проблемноори
ентированных языков (ПОЯ).
Имеется еще один принципиально важный источник сложности, затрудняю
щий «взаимопонимание» с компьютерами. Речь идет об отсутствии в современ
ных компьютерах модели реального мира, согласованной с представлениями
о мире у программистов и пользователей. Поэтому в общем случае компьютер не
в состоянии контролировать указания программиста или действия пользователя
с прагматической точки зрения (контролировать соответствие между действиями
и теми целями, ради которых эти действия совершаются, – цели компьютеру не
известны).
Изза этого самая «мелкая», с точки зрения создателя программы, описка мо
жет привести к совершенно непредсказуемым последствиям (широко известен
случай, когда изза одной запятой в программе на Фортране взорвалась космичес
кая ракета, направлявшаяся на Венеру; пропали усилия, стоившие миллиарды
долларов).
Итак, в качестве второго источника сложности в современном программирова
нии следует назвать незнание компьютером реального мира. Лишенный необходи
мых знаний, компьютер не может не только скорректировать неточно указанные
в программе действия, но и проинформировать об отклонениях от направления на
35

36
цель работы. Традиционное для компьютеров управление посредством указания
действий, а не целей требует учета мельчайших нюансов всех обстоятельств, в ко
торых может оказаться исполнитель в процессе предоставления нужной услуги.
Это резко увеличивает число объектов, с которыми приходится иметь дело при
создании программ. Отсюда повышение сложности программирования, увеличе
ние размера программ, понижение их надежности и робастности.
Со вторым источником сложности борются, развивая методы представления
в компьютерах знаний о реальном мире и эффективном учете этих знаний при
создании и исполнении «дружественных» программ.
Современное состояние языков программирования
1.14. Два основных средства
борьбы со сложностью.
Основной критерий качества ЯП
Рассмотренные источники сложности оказывают определяющее влияние на тео
рию и практику в области ЯП. Важнейшим средством борьбы с семантическим
разрывом служит аппарат абстракцииконкретизации, имеющийся в том или
ином виде в любом ЯП. Именно этот аппарат – основа проблемной ориентации
языковых выразительных средств.
Например, в Фортране характерное средство абстракции – подпрограмма,
а соответствующее средство конкретизации – обращение к ней с фактическими
параметрами. Поэтому естественный ПОЯ, создаваемый посредством Фортра
на, – набор (пакет) проблемноориентированных подпрограмм. В более современ
ных ЯП применяют более развитые средства абстракции (абстрактные типы дан
ных, кластеры, фреймы) и соответствующие средства конкретизации (о которых
мы еще поговорим). Становятся более богатыми и возможности строить ПОЯ.
Важнейшим средством борьбы с незнанием реального мира служит аппарат
прогнозированияконтроля. Имеются ЯП, в которых этот аппарат практически
отсутствует (Апл, Форт, Лисп) или очень слаб (любой ассемблер). Однако имен
но этот аппарат – основа повышения надежности и робастности программ. Послед
нее не означает, что «дружественные» программы невозможно писать на ЯП со
слабым прогнозированиемконтролем. Просто в этом случае создание подходя
щего аппарата полностью возлагается на программиста.
Например, в Фортране характерное средство прогнозирования – встроенные
(предопределенные) типы данных. Соответствующий контроль предусмотрен се
мантикой языка, но средств управления таким контролем нет (новые типы дан
ных вводить нельзя). В таких ЯП, как Паскаль или Ада, этот аппарат более развит,
а в так называемых языках искусственного интеллекта он прямо предназначен
для представления достаточно полных знаний о мире, целей деятельности и конт
роля действий как самой программы, так и пользователя.
Упражнение. Приведите примеры средств абстракцииконкретизации и прогнози
рованияконтроля в известных вам ЯП. Постарайтесь подобрать симметричные,

Концептуальная схема языка программирования
взаимно дополнительные средства. Убедитесь, что эта дополнительность обеспече
на не всегда.
Теперь мы готовы сформулировать следующий основной критерий качества
ЯП (как инструмента, то есть с технологической позиции): язык тем лучше, чем
менее сложно построенное на его основе производство программных услуг.
На этом оставим пока технологическую позицию и займемся семиотической.
37
1.15. Язык программирования
как знаковая система
Продолжим уточнение понятия «язык программирования». Наше новое интен
сиональное определение ЯП таково:
язык программирования – это знаковая система для планирования поведения
компьютеров.
Итак, не любой «инструмент», а «знаковая система», и не для произвольных
«исполнителей», а только для компьютеров. К ограничению класса исполнителей
в этом определении мы подготовились заранее, а вот о знаковых системах еще
подробно не говорили.
Знаковая система – это совокупность соглашений (явных или неявных), оп
ределяющих класс знаковых ситуаций. Понятие знаковой ситуации в семиотике
относят к первичным понятиям, представление о которых создают с помощью
примеров, а не явных определений. Необходимые компоненты знаковой ситуа
ции – знак и денотат. Говорят, что знак обозначает денотат (знак называют так
же обозначением, или именем, а денотат – обозначаемым, или значением). Так,
в модели передачи сообщения само сообщение служит знаком, его смысл – дено
татом.
Вот еще знаковые ситуации (первым укажем знак, вторым – денотат): буква и
соответствующий звук, дорожный знак («кирпич») и соответствующее ограниче
ние («въезд запрещен»), слово и соответствующее ему понятие. Каждый без за
труднений пополнит этот список.
Когда класс знаковых ситуаций определяется совокупностью соглашений
(правил), устанавливающих закономерную связь между структурой знака и его
денотатом, говорят, что эти соглашения образуют знаковую систему (или язык).
При этом правила, определяющие структуру допустимых знаков, называются
синтаксисом языка, а правила, определяющие соответствующие допустимым зна
кам денотаты, называются семантикой языка. (Науку о синтаксисах языков назы
вают синтактикой, а слово «семантика» используется для обозначения как конк
ретных правил некоторого языка, так и общей науки о таких правилах.)
Одним из примеров знаковой системы служит позиционная система счисле
ния (например, десятичная). Правила, определяющие перечень допустимых цифр
и их допустимое расположение (например, справа налево без разделителей), – это

38
синтаксис. Правила вычисления обозначаемого числа – семантика. При этом
запись числа в позиционной системе – знак, а само обозначаемое число – денотат.
Известные вам ЯП – также знаковые системы.
Упражнение. Приведите пример синтаксического и семантического правила из та
ких знаковых систем, как Фортран, Бейсик, Паскаль, Ассемблер.
В общем случае в ЯП знаки – это элементы программ (в том числе полные про
граммы), а денотаты – элементы и свойства поведения исполнителя (атрибуты
его поведения), в частности данные, операции, управление, их структура, их связи
и атрибуты. Например, знаку, составленному из шести букв «arctan» (элементу
программы на Фортране), использованному в этой программе в подходящем кон
тексте, соответствует в качестве денотата такой элемент поведения исполнителя,
как вычисление арктангенса.
Знаку, составленному из двух букв «DO» (элементу программы на Фортране),
в одном контексте в качестве денотата может соответствовать такой элемент пове
дения, как вход в цикл, а в другом – переменная вещественного типа, в третьем –
массив целого типа.
Упражнение. Выпишите подходящие контексты.
Итак, знаковая система – это правила образования знаков (синтаксис) и согла
сованные с ними правила образования денотатов (семантика). Подчеркнем, что
правила использования денотатов для целей, выходящих за рамки семантики (то
есть прагматика), обычно не включаются в знаковую систему. Например, в Форт
ране нет какихлибо правил, ограничивающих применение соответствующих
вычислительных процессов для неблаговидных целей.
Теперь уточненное определение ЯП как знаковой системы для планирования
поведения компьютеров должно быть полностью понятным.
Современное состояние языков программирования
1.16. Разновидности
программирования
Чтобы создать себе более удобную основу для формирования оценок, принципов
и требований, примем соглашения, сужающие область наших рассмотрений.
Вопервых, программировать можно с разной целью. Например, для развлече
ния и обучения («игровое» программирование, его характерное свойство – инте
рес не столько к программерезультату, сколько к самому процессу программиро
вания); для отработки идей, приемов, инструментов, методов, критериев, моделей
(«экспериментальное» программирование, его характерное свойство – созданная
программа не предназначена для применения без участия автора, то есть резуль
тат такого программирования неотчуждаем). В дальнейшем будем рассматривать
только «индустриальное» программирование, цель которого – создание про
граммных изделий (программных продуктов) на заказ или на продажу. Характер
ное свойство – отчуждаемость результата.

Концептуальная схема языка программирования
Вовторых, может быть различным характер использования заготовок про
грамм. По этому критерию различают, по крайней мере, три разновидности про
граммирования:
• сборочное – программа составляется из заранее заготовленных модулей
(так обычно сейчас работают пакеты прикладных программ);
• конкретизирующее – программа получается в результате преобразования
универсальных модулейзаготовок (в результате их специализации) в рас
чете на конкретные условия применения; цель специализации – повышение
эффективности (снижение ресурсоемкости) универсальной программы;
• синтезирующее – роль заготовок относительно невелика.
В дальнейшем нас, как правило, будет интересовать лишь синтезирующее ин
дустриальное программирование, а также элементы сборочного программирова
ния (когда речь пойдет о модульности).
Втретьих, на различных стадиях жизненного цикла программного изделия
(из которого мы выделим стадии проектирования, эксплуатации и сопровожде
ния) предъявляются различные, иногда противоречивые, требования к ЯП. На
пример, сложность программирования не столь существенна на стадии эксплуа
тации программы, как ее ресурсоемкость. На стадии проектирования важно
удобство написания программ, а на стадии сопровождения – удобство их чтения.
В первую очередь будем интересоваться стадией проектирования программного
изделия, так как на ней в той или иной форме следует учитывать и требования
всех остальных стадий жизненного цикла.
Итак, мы в сущности определили основной стержень нашего интереса, сфор
мулировали основной критерий отбора аспектов ЯП, которым будем уделять
в этой книге основное внимание. Нет серьезных оснований претендовать на то,
что именно такой стержень обладает какимито особенными преимуществами.
Вдумчивый читатель сможет применить полученные навыки анализа ЯП и при
иных исходных соглашениях.
39
1.17. Понятие о базовом языке
Два выделенных источника сложности – семантический разрыв и незнание ми
ра – полезно трактовать как два различных аспекта единого источника: рассогла
сования моделей проблемной области (ПО) – области услуг, задач, операций
у пользователей и исполнителей.
При таком взгляде создаваемая программа выступает как средство согласова
ния этих моделей. Чем ближе исходные модели, тем проще программа. При иде
альном исходном согласовании программа вырождается в прямое указание на
одну из заранее заготовленных услуг (например, «распечатать файл», «взять про
изводную», «выдать железнодорожный билет»). Мера рассогласованности моде
лей положена в основу известной «науки о программах» Холстеда.
Мы уже говорили об исключительном разнообразии моделей даже одного
объекта, рассматриваемого с различных точек зрения. Поэтому невозможно по
строить исполнителя, непосредственно пригодного для выполнения любой услу

40
ги. Однако удается строить специализированные исполнители и ориентировать
их на фиксированный класс услуг – ПО. Для управления такими специализиро
ванными исполнителями создаются проблемноориентированные языки (ПОЯ).
В качестве хорошо известных примеров укажем язык управления заданиями
в операционной системе, язык управления текстовым редактором, язык запросов
к базе данных и т. п.
Итак, ПОЯ опирается на определенную модель соответствующей ПО (иногда
говорят, что эта модель встроена в такой язык; точнее говоря, ПОЯ – это знаковая
система, для которой модель соответствующей ПО служит областью денотатов).
Так что безнадежно строить ЯП с моделями, заготовленными «на все случаи
жизни». Однако можно попытаться построить ЯП, на базе которого будет удобно
(относительно несложно, с приемлемыми затратами) строить модели весьма раз
нообразных ПО. Такой язык называют базовым языком программирования.
Обычная схема применения базового языка в определенной ПО состоит из
двух этапов. На первом (инструментальном) создаются модель ПО и соответству
ющий ПОЯ (их создают с помощью базового языка программистыконструкто
ры). На втором (функциональном) этапе программистыпользователи решают
прикладные задачи, пользуясь созданным ПОЯ. Впрочем, иногда ПОЯ в сущнос
ти уже и не язык программирования, так как с его помощью ведут диалог с компь
ютером, а не планируют поведение заранее. Соответственно, и пользователей та
кого ПОЯ обычно программистами не называют.
С другой стороны, сам базовый ЯП также можно считать специализирован
ным ПОЯ со своей ПО – он предназначен для построения моделей других ПО и
соответствующих ПОЯ. В дальнейшем будем рассматривать именно базовые ЯП,
точнее базовые ЯП индустриального программирования.
Современное состояние языков программирования
1.18. Концептуальная схема
рассмотрения ЯП
Завершая подготовку к систематическому изучению ряда моделей ЯП, зафикси
руем единую схему их рассмотрения. Эта схема поможет сопоставить и оценить
различные ЯП прежде всего с точки зрения их пригодности служить базовым
языком индустриального программирования.
Если бы нас интересовала, например, оценка ЯП с точки зрения легкости их
усвоения начинающими программистами, мы предложили бы, конечно, другую
схему их рассмотрения, начав с выявления основных целей и проблем обучения,
наиболее подходящих средств решения этих проблем и т. д., подобно нашему пути
к базовому языку.
Тем самым предлагаемую ниже схему нужно воспринимать и как демонстра
цию существенного элемента систематического метода сравнительной оценки
языков. (Конечно, наша учебная схема намного проще той, которую следовало бы
строить при практическом решении вопроса о пригодности конкретного ЯП слу
жить базовым языком индустриального программирования.)
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
