Лекция 1 (Лекции (2009) (Саша Федорова))

8

Лекция 1

Пункт 1: Определение ЯП

Существует куча неудовлетвоительных определений ЯП.

Как и в любой науке, сущестувует 2 вида определений:

-экстенсиональный

-интенсиональный

Экстенсиональный – простой. Определяющий понятие через его обьем. В этом смысле ЯП – это Си++/Си, Паскаль. (Остановиться здесь должно и на языке Ассемблере, но машинную реализацию мы разбирать не будем).

!954 – 1957 гг – разработка ЯП Фортран. С 1957 года ЯПы стали появляться как «опята».

В 1967 году Джин Санди собрала кое-какие сведения об использовавшихся в Европе языках программирования. Сколько было тогда языков программирования?

Тех, которые не просто были описаны, но использовались, насчитывалось уже тогда порядка 700.

Через 10 лет появилось переиздание этой книги – речь шла уже о тысячах ЯП. С тех пор попыток посчитать число языков программирования не было. 

Сейчас одних лишь самых известных Яп насчитывается порядка около 100, а всего ЯП –ов – порядка десяти тысяч.

Отсюда следует, что определять ЯП через экстенсионал – не исп очень хорошо.

Декларативность никакого отношения не имеет. Более интересно второе определение языка программирования – через его родовые и естественные признаки.

Кауфман в своей книге сказал, что ЯП – это инструмент планирован

Вообще говоря, программирование – это использование компьютера. Однако родовое понятие ЯП зависит в 1 очередь от исполнителя, который должен зависеть от поведения(людей, например), которым надо управлять.

Самый популярный исполниель – это компьютер.

Однако существуют системы, которые определячлись не для использования компьютером.

PLANNER

Придуман сей ЯП был для искусственно интеллекта(знаковая система).

Planner придумал некую нотацию. Чье поведение должен был планировать PLANNER?

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

В 1980 году аспирант факультета ВМиК отрезал от PLANNERа ту часть, которую мождно было реализовать на машине, и назвал его ПЛЭНЕР. Это был Владимир Николаевич Пильщиков. 

Еще 1 интересный язык – APL. Появился в начале 1960-х гг. Был разработан Кеном Иверсоном, тогда еще сотрудником IBM. Предназначен был для реализации операций Линейной Алгебры. Данный ЯП был коротким и компактным, что делало возможным его использование для записи математических алгоритмов. ЯП в некотором смысле мертвый. Одна из причин этого состоит в том, что, будучи языком, предназначавшихся для компактной записи алгоритмов, АРL был плохочитаемым. А сейчас читабельность очень важна.

Пример: если взять естественные языки – является ли русский язык инструментом планирования поведения исполнителя?

Как можно планировать что-либо, если сам план поведения неоднозначен?

Примеры синтаксически неоднозначных предложений:

Привет освободителям востока от Дзержинского.

(2 смысла, второй из которых проглядывается меньше. Но проглядывается.)

Еще пример(из учебника по английскому) :

Джон проектирует в колледже в Лондоне.

Тощая торговка вяленой воблой сидела у прилавка.

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

Явна лишь сама система предпочтения одного смыла другому.А в ЯП нет такой системы. Наш мозг уже приспособлен фильтровать эти естественные неоднозначности.

С другой стороны, если выделить из естественного языка его часть, то можно получить инструмент для планирования поведения исполнителя. Существует некий командный язык, являющийся подмножеством самого языка, который может быть Языком Планирования.

Пример: HTML – это ЯП. Исполнителем является браузер, его задача – отобразить текст на экране(вполне конкретная задача).

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

Примечание:

Зачастую в процессе написания программы мы фактически СОЗДАЕМ исполнителя. Чем же тогда является конфигурационный файл? Это программа. И тогда понятно, что проектировать конфигурационные файлы надо совсем иначе. Сами программы логичнее рассматривать как интерпретаторы конфигурационных файлов.

Итак, под исполнителем с данного момента мы будем понимать некую вычислительную систему. А ЯП – это инструмент для написания планов.

Что же необходимо для эффективного планирования?

- возможность прогнозирования поведения исполнителя

-контроль(система контроля)- без него никакого эффективного планирования не будет.

Рассмотрим ситуацию на примерах.

Чем отличается С++ от Питона? С++ от Лиспа?

Чем отличается Java от JavaScript? С# от JavaScript?

В первых ЯП есть система классов, подразумевающая возможность контроля, а во вторых отсутствует как статический, так и динамический контроль. Различают сильно и слабо типизированные ЯП.

Чем выше степень контроля, тем эффективнее соотвествующая программа.

Пункт 2

Основные позиции рассмотрения ЯП

Мы будем заниматься не всеми ЯП. Заметим, мы до сих пор не назвали BASIC и ряд других ЯП. Мы рассматриваем не любой ЯП. Заметим, что существует различные виды программирования. Мы будем рассматривать лишь ЯП с исполнителем – Вычислительной системой.

С нашей точки зрения отметим 3 виду программирования:

1- игровое –(первый смысл – серьезная индустрия с серьезным доходом, занимающаяся программированием игр, а в нашем понимании – программирование для себя, программирование как игра, как развлечение.) Особого смысла в игровом программировании нет, ровно как и прикладной полезности от него не дождешься. Студент, сдающий задание по практикуму, зачастую относится к его выполнению именно как к игровому программированию. А преподаватель пытается заставить писать программу в ином стиле – индустриальном.  Читать плохие программы, написанные в игровом стиле, невозможно. А профессионал уже не может писать непрофессиональные программы.

ЯП, подходящий для игрового программирования(учебное программирование часто рассматривается именно как игровое) зачастую не подходят для профессионального программирования.

1964г – BASIC – классический язык для игрового программирования.

Компьютерам IBM PC не нужны были даже дисководы. Если он либо жесткий диск отсутствовал, попросту начинал загружаться интерпретатор BASIC. Правда, по причине отсутствия дисковода сохранять результаты такого программирования оказывалась затруднительно… А стоило ли их сохранять?

2 – научное программирование.

В данной области человек пишет программу для себя. Программы нужны для конкретных целей(люди с 1 потока факультета ВМК).

Пример. Человек занимается разведкой нефтяных месторождений. В процессе разведывания возникает матричное уравнение, которое удобно разрешить на компьютере. Человек пишет некоторую программу. Математическая модель обсчитана. Результат нужен небольшому числу людей(1-5). Таким образом, ученый проверяет свои догадки и результаты эксперимента. Многого ему не надо, ведь ученый не может тратить много времени на написание программ. Программы может быть корявой, может валиться на некоторых местах. Ну и пусть. Зачем исправлять? 

Для научного программирования подходят языки, на которых легко писать. Корявость здесь не важна. Программирование в научных исследованиях – это некий этап, который надо поскорее пройти.

3- Индустриальное программирование или программирование не для себя.

В этом случае мы создаем полностью отчуждаемую программу в пользу третьих лиц. Это создание программного продукта– созданная программа будет отчуждена от автора и использоваться будет вне его, НЕ автором. Тут уже не играет роли, зачем человеку надо заниматься написанием программы.

Роль и понятие ЯП будет различаться в зависимости от его типа.

Основные требования для игрового программирования – простота его освоения и легкость применения.

К научному языку – минимум хлопот и минимум времени. Фортран – контр-пример, каким НЕ надо делать ЯП. В то же время, он очень важен для целого класса людей. Он прост и в изучении, и в программировании на нем.

Написать компилятор на Фортане будет тяжеловато. Но зачем это математику?

Fortran=Formula Translate

Плевать, что Фортран – плохой ЯП. Не важно, что он не годен для индустриального программирования.

Мы, как будущие программисты, будем рассматривать те ЯП, которые пригодны для индустриальнооо программирования, то есть для создания Программного Продукта.

Требования:

-эффективность

-модифицируемость

-читаемость

Конец 60-х гг – кризис в программировании.

Начало 70-х годов –Начало проектирования системы IBM – 360. Эта архитектура была анонсирована в 196-м году. А создана была лишь в 1964. Что же длилось 3 года

Разработкой ОС руководил Фредерик Брукс. По итогам этой работы он написал знаменитую книгу «Мифические 9 месяцев».

До этого программы такой сложности не создавались. А создание данной ОС предполагало код огромного масштаба. Разрабатывали его 3(почти 4) года.

Примечание. Microsoft Windows, кстати, ни разу не выполнил обещание вовремя выпустить новую ОС,

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

А что-нибудь сильно изменилось за это время?

Когда нам обещали WInEFEC? 

Общая мысль: кризис перешел в вялотекущую фазу.

Пример.

В начале 70-х годов Пентагон решил проанализировать, куда уходят деньги на программы(противоракетной обороны, например).

Выяснилось следующее. Затраты на написания программного обеспечения – это всего лишь 50 процентов от затрат. Пока программа не снята с учета, пора вложить те самые оставшиеся 50 процентов на сопровождение ПО. А «первые» 50 процентов – это, собственно, что? Собственно программирование – это 10 процентов. 25 процентов уходит на тестирование. Остальное – ТУ и ТГ.

Что-то надо было с этим делать.

В итоге. Из чего складываются затраты на сопровождение?

- исправление ошибок

-меняются требования пользователя.

Пример. СССР – «Сирена -2».(бронирование ж/д билетов) – ТУ и ТГ. Старые матричные принтеры – 1 длинный рулон бумаги. Сейчас уже нет ни страны, ни заводов – а принтеры ломаются. Аппаратура вышла из строя, а новую такую не найдешь.

А ведь люди, которые занимаются сопровождением ПО, именно ЧИТАЮТ программные коды. Может, мы начнем писать ЧИТАЕМЫЕ программы?

Существуют 7 позиций :

1. Технологическая.

2. Авторская

3. Реализаторская

4. Сениотическая

5. Социальная.

Технологическая позиция. Существует некая технология программирования. Любая технология выдвигает ряд требований. Одна из составляющих частей идеологий программирования при использовании UNIX- это собирать и разбирать. Идеология Unix (ленточный архиватор – позволяет собирать кучу файлов в 1 файл. Задача – просто компрессировать. Использование UNIX - это совместное использование разнографичных инструментов. Программирование под UNIX – это создание набора инструментов. «Software Tools» - книжка Брайан Керниган. А потом появилась полемика – что лучше. Паскаль или Си. Затем Брайан Керниган написал книгу «Инструмент программирования в Паскале».

«Software Tools in PASCAL»+ статья «16 причин того, что Паскаль не является моим любимым языком программирования», необходимых для индустриальной разработки ПО, не реализованных в Паскаль. В том числе – возможность реализации в команде- модульность. При быстром создании ПО делают команду, что предполагает разбиение программного кода на части (модули). А в стандартном Паскале(без расширений) модульности нет вообще.

Итог: технологические потребности формируют соответствующие конструкции ЯП.

Критичная технологическая потребность – та, то делает ЯП неадекватным. Технологическая потребность – самая важная.

Авторская позиция.

Любой ЯП – это совокупность компромиссов.