Костин Г.В.
Все в этой книге может оказаться ошибкой.
Р. Бах. Иллюзии
Поскольку процесс программирования есть процесс переноса мыслей от разработчика к компьютеру, ЯП исполняет роль интерфейса, шлюза между человеком и компьютером
Для начала введу понятие "карта". В психологии "перцептивная карта реальности" определенна как индивидуальная модель восприятия каждого человека, являющаяся результатом его предшествующего опыта. Т.е. что у человека в голове. Допустим, стол ассоциируется у русскоязычного человека со словом стол, у француза со словом table, у англичанина или американца со словом Desktop. Переводя на язык компьютеров, карта - это содержимое памяти компьютера. И человек и компьютер реагируют на внешние события (т.е. входную информацию) в соответствии с содержимым своей карты. Допустим, индонезиец слово "Кретин" воспримет как "кудрявый", а слово "сука" как "любить". О фразах "Хулиа, пидерас лас охуэлас?" - "Юля, ты попpосишь блинчиков?" и "Ун трахэ негро пара ми ньета" - "Черный костюм для моего племянника я уже не говорю. Аналогично, компилятор C++, встретив "{" воспримет ее как начало логического блока, а компилятор Паскаля - как начало комментария.
Для осуществления коммуникации (т.е. для передачи информации) между двумя субъектами (компьютеры, люди...) необходимо, чтобы их карты хотябы частично совпадали. Необходимая часть как раз и есть язык. Допустим, компьютер под Windows может общаться с NetWare сервером лишь говоря на его "языке"(интерфейс IPX/SPX).Работая с Unix, вы не сможете использовать команды Dos, а с Dos - Unix. Аналогично, общаться с иностранцами Вы сможете лишь на известном обоим языке. Более того для общения с профессором и со слесарем Вы вероятно тоже выберете разные "интерфейсы". В психологии подбор интерфейса под собеседника носит названия подстройка. На ней основан Эриксоновский гипноз и НЛП.С помощь ю её можно навести транс и вывести человека из комы.
Для осуществления же не просто коммуникации, а эффективной коммуникации необходимо более полное совпадение карт. Если язык общения не будет родным, то субъект коммуникации будет терять ресурсы на "перевод". Допусти сервер под ОС Linux эмулируя сервер WinNT будет показывать значительно меньшую производительность, чем та на которую он способен будь этот интерфейс для него родным. Аналогично программист, общаясь с бухгалтером, будет тратить время на перевод "проводок" в транзакции.
Процесс разработки ПО и ЯП
На рисунке изображен процесс разработки ПО с точки зрения ЯП.
Здесь я рассмотрю разработку ПО как процесс последовательной детализации.
Справа изображен пользователь, от которого программисту поступает небольшое количество информации. Слева изображен компьютер, которому, в конечном счете, разработчик должен будет представить программу в бинарных кодах, т.е. очень большое количество информации.
Пунктирными линиями изображены уровни детализации, такие как ЯП C++ или Техническое задание. В процессе разработки программист движется справа налево от пользователя к компьютеру. На рисунке разработчик находится примерно на уровне проектирования программы.
Детализация проводится либо автоматически, к примеру, использование генерации кода по спецификациям, допустим, Corba IDL или генерация кода программы по графическим спецификациям интерфейса в JBuilder, либо вручную, к примеру, кодирование в двоичных кодах подпрограммы по спецификации на ЯПВУ или реализация класса по спецификациям.
Естественно, первый вариант существенно повышает производительность труда разработчика. Т.е. допустим если разработчик на уровне технического задания тратит 5 минут то на уровне проектирования ему потребуется 50, а на уровне реализации 250. Именно поэтому эволюция ЯП да и программирования в целом движется в направлении от компьютера к человеку.
Я имею в виду не всю длительную и трудоемкую стадию анализа, а лишь формальное описание требований к ПО на его уровне. Поэтому приводимые данные не следует рассматривать как преуменьшения значимости стадии анализа.
На каждом уровне абстракции существуют свои языки. ЯП же выступает как интерфейс на различных уровнях. При этом за спецификацией (справа пунктирных линий на рисунке) скрывается спецификация(слева пунктирных линий на рисунке). К примеру, спецификация цикла For скрывает его реализацию также как спецификация класса скрывает спецификацию его.
Касательно языка:
Чем ближе ЯП к компьютеру и дальше от разработчика, тем больше будет размер исходного кода программы на нем, сложность его написания, широта возможностей, предоставляемых языком, и качество генерируемого кода. Из близости к человеку будут следовать переносимость разрабатываемого ПО и его безопасность, низкий уровень детализации и, естественно, более высокий уровень ЯП.
Впрочем, отмечу, что преимущества и недостатки ЯП обусловлены не только этими факторами, к примеру, типизация неадекватна ни человеку, ни машине. Она возникает на промежуточном уровне - 3GL отсутствуя на предыдущем - ассемблеры и на последующих - сценарные и неимперативные языки
<
Ширина прямоугольника ("горизонтальный размер языка") обозначает широту средств языка по уровням абстракции. Поясню на примере. C++ - это язык с очень большой "шириной": он взял в себя средства и от низкоуровнего ассемблера, и от ЯПВУ. На нем можно реализовать и драйвер, и АСУП. Притом в случае, если в язык будут вставлены высокоуровневые средства создания интерфейса пользователя, работы с БД и т.д., как это предлагает Страуструп, то он станет еще "шире". Java - язык значительно более "узкий". И драйвера на нем писать не удастся.
Длина прямоугольника ("вертикальный размер языка") обозначает широту средств языка по областям применения. Фактически спектр типов приложений, на которые этот язык рассчитан.
Поясню на примере - PL/1 и C++ одинаково годятся и для разработки финансового пакета, и для компьютерной игры. Они имеют большую "высоту" средств.
MatLab, JavaScript имеют маленькую "высоту". Их эффективно можно использовать лишь в той единственной области, для которой они созданы (в данном случае математика и Web - скрипты).
Как известно, длина, умноженная на ширину, даёт площадь. Это объем средств языка.
Есть мнение, что сложность и размер языка должны быть соразмерны с размерами задачи.
Хотя не все специалисты и ученые согласны с тезисом, что сложность и размер языка должны быть соразмерны с размерами задачи. К примеру, Вирт разработал ОС Oberon на очень простом языке Oberon с минимальными средствами.
Тут есть два крайних варианта:
В ЯП следует включать только такие концепции и конструкты, без которых совершенно невозможно обойтись. Яркий пример - Оберон
В ЯП следует включать все, что когда - либо может понадобиться разработчику - яркий пример - Ада. На практике, как правило, используется нечто между этими двумя полюсами.
Касательно сложности ЯП отмечу следующее:
Вообще сложность ЯП и сложность его использования для тех или иных задач понятия разные и не всегда коррелирующие друг с другом. Попробуйте написать более не менее сложную программу на оригинальном Basic...
Тут следует учесть и человеческий фактор.
Простота использования невысока у высокоуровневых средств лишь для задача для которых они предназначены. К примеру разработка простенькой БД в Accses значительно проще, чем Delphi. Но разработка серьезного клиент - серверного АРМ'а на Delphi может оказаться проще.
Человеческий фактор в ЯП
"...что на изменение привычек и поведения людей всегда уходит гораздо больше времени, чем хотелось бы..." Бьорн Страуструп
...исследования психологов ясно показали, что люди постоянно ошибаются: пишут ли они программы, разрабатывают ли математические доказательства, управляют ли самолетом...
Иногда разработчики занижают уровень языка. К примеру, разрабатывают на C++ программу, которую можно было разработать на Perl за в несколько раз меньшее время
"..реагируют на эту мою позицию с неистовством, выходящим за рамки отношений, которые я считаю уместными при обсуждении языка программирования." Бьярн Страуструп
Постоянный приток в сферу разработки ПО "программистов по случаю". Они добавляют популярность и таким средствам, как Perl,TCL,1C,PHP.
Ограниченная размерность решаемых задач. Программист не может одновременно держать в голове подробно достаточно сложный фрагмент кода. Поэтому в ЯП включаются средства для декомпозиции ПО - подпрограммы, модули, классы.
Не только ЯП формирует мышление, но и мышление - язык и даже "железо".
Приведу пример.
Контроль за выходом индекса границ массива почти не замедляет выполнения программы, т.к. проверка у процессоров 80x86 реализуются на аппаратном уровне.
Таким образом, такая особенность человеческой психики, как невозможность безошибочной работы по средствам ЯП отразилась на железе.
Лёгкость понимания программы человеком. Компьютер программу компилирует, а читает и модифицирует её человек. Успешность этого процесса в значительной степени зависит от легкости понимания программы. В частности, синтаксиса языка.
Стиль мышления.
Напомню, что "Язык формирует наш способ мышления и определяет, о чем мы можем мыслить.". Парадигмы программирования являются и парадигмами мышления программиста".
Качество программы определяется качеством мышления.
Резюмируя, отмечу, что разница между человеком и компьютером очень велика. Язык служит [промежуточным звеном] для преодоления этой разницы.
ЯП языки - явление прежде всего социальное, а научное. Умозрительные критерии и оценки достоинств и недостатков языков, по меньшей мере, неубедительны - основной критерий: практика массового использования.
Умозрительно мы можем рассматривать лишь ограниченное число абстрактных критериев. И не факт, что выберем основные. Тем более, что необходимо учесть и психологические, и экономические факторы. Единственное требование к использованию языка - это адекватность применения.