Парадигмы программирования, 11 лекция (от 03 декабря)

Материал из eSyr's wiki.

Текущая версия

• Аудиозапись: http://esyr.org/lections/audio/paradigms_2009_winter/paradigms_09_12_03.ogg

Через неделю будет экзамен. Список экз. билетов выложен по адресу: http://www.stolyarov.info/pvt/par_exam (возможно, дефис вместо подчёркивания). На всякий случай: лектора можно добыть по электронной почте (адрес уехал в history). Адрес не для публикации, использовать, если что-то необх. сообщить отн. списка вопросов. Возможно, последние два вопроса, если сегодня не успеет их лектор, будут выкинуты.

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

На 4 балла — все лекции кроме двух, на 3 — 2/3 с округлением вниз. (7 из 11)

Можно ли будет сдать кзамен когда-то ещё? Можно, но это уже будет в сессию. Для этого нужено найти лектора на кафедре и договориться.

Традиционные парадигмы программирования: императивные и всё, что с ними связано (ООП, ...)

Императивная, или фон-неймановская парадигма. Какое самое главное слово в императивном программировании: присваивание. Программа имеет состояние, и она состоит из его изменения. Переменная, как область памяти и присваивание.

В императивном программировании есть неявная составляющая состояния. Мы из теории автоматов знаем, что такое состояние. Есть неявная составляющая состояния: как минимум, значение IP. Эта неявная составляющая является в мышлении некоторых настолько важной, что они не могут написать событийную модель без использования тредов. К сожалению, лектор не смогу убедить в необходимости рассказывать про системный вызов select, позволяющий ожидать одно из множества событий.

....

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

Определение автоматного программирования: фрагмент кода может быть оформлен в виде чего-то, напоминающего конечный автомат. Принципиально что: шаги автомата не перекрываются по времени. Между шагами автомата информация может передаваться только через явно очерченный круг переменных.

Есть такой человек, Алан Кокс, одно время был senior architect ядра Линукс. Он в своё время сказал такую вещь: компьютер это конечный автомат, и те, кто плодят треды, не знают, как пользоваться компьютером. Альтернатива — только треды. Для тех, кто не может распознать сост. состояния и использовать её.

Теперь мы заговорили на событийно-ориентированное программирование. Известно, что событийно-ориентированные программы приятне всего писать на ОО-языке. Ещё со времён smalltalk'а. Тогда же появилась Симула, которая предназначалась для имитационного меоделирования и хорошо для него подходит. Неоднократно лектору приходилось встречаться с таким утверждением: ООП не более чем разновидность императивного программирования. Утверждение неверное категорически. Откуда оно берётся? Скорее всего из того, что ОО-языки в большинстве своём императиные. С другой стороны, есть Common Lisp Object System [1], но никто же не утверждается, что ООП — это слегка измененное функциональное программирование. Поэтому ОО не является ни функциональным, ни императивным программированием. Как доказать это: для ОО-программирования присваивание является возможностью посторонней. В чистом ОО присваивание быть не может. Что такое присваивание? Это полная замена состояния переменной. Теперь вспоминаем, что такое ООП? В ООП среда выполнения программы представляет как набор чёрных ящиков, называемых объектами, т. е. системами, с внутренностями которых нельзя ознакомиться, только со внешними проявлениями. Известно, что объект может принимать сообщения и отвечать на них. При этом он можнет изменять собственное состояние и обмениваться с другими объектами сообщениями. При этом мы не знаем, сменил ли объект состояние полностью или нет. Потому что это нарушает принцип инкапсуляции. Поэтому присваивание в чистом ОО быть не может. Если же допускается, то это означает, что ЯП поддерживает не только ООП.

С ОО, поговорим о нём ещё. Более практическая терминология заменяет понятие отправки сообщений на понятие "вызов метода". Ответ на сообщение — результат вызова метода. Теперь чуть дальше. В ОО есть классы. Это нечто, фабрика объектов, экземпляров класса. То есть классы это что-то, позволяющее создавать объекты, одинаковые по внутреннему устройству. Отсюда класс есть множество объектов. Конечно, не любое множество объектов является классом. В таких терминах можно определить понятие наследования. Когда мы наследуем, то мы добавляем свойства. Это означает, что мы множество сузили. Когда мы сужаем множество, то мы можем сказать что-то дополнительное о них. При этом A ⊃ B.

Теперь лектор собственно хотел сказать про ещё одну интересную парадигму, точнее, класс языков. Есть класс языков, по крайней мере, большинство из них является императивными, языки эти называются командно-скриптовыми. С точки зрения лектора, класс языки определяется тремя моментами:

• Строка — наше всё. Строка текста как универсальный представления для любых типов данных, а также самой программы.
• Развитые и легко применимые средства запуска внешних программ и управления ими.
• (в принципе, являющеяся, следствием первого) Функция eval.

Почему eval возник здесь? Потому что для кода и для данных одно представление, и программа может во время работы слепить кусок кода и подать его на вход интерпретатору. Где такое ещё есть: в lisp.

Кто-то может сказать, что строка не является общим представлением. Есть такой язык tcl, раньше это было так, сейчас не совсем, но есть полная иллюзия того, что работа всё равно со строками. Когда это становится видно: когда его встраиваем или расширяем. Тогда мы видим, что там возникают полиморфные объекты, но внутри это не видно.

Что здесь интересно: в КС языках очень интересна скорость разработки. Благодаря тому, что есть простое средство управления внешними программами, то можно их очень быстро слепить. Более того, если мы возьмём КС-язык, который изначально был придуман как язык управления заданиями, тот же самый bourne shell, то там мы можем обнаружить такую вещь, как алгебру программ. Так вот, если рассмотривать это как некий объект со стандартным вводом, выводом и командной строкой, то можно заметить два способа суперпозиции: конвейер и обратные апострофы.

Кроме того, это позволяет связывать программы, в том числе, написанные с использованием разных парадигм.

Последнее, что лектор хочет сказать: а давайте посмотрим внимательно на понятие ascii-текст. Вообще, это понятие может использоваться для хранения чего угодно, это своевременно обнаружили, и в результате большинство протоколов текстовые, конфигурационные файлы текстовые. Что это позволяет? Встраиваться программисту в цепочку работы программ, например, в целях отладки. Кроме того, ascii есть везде, а с юникодом и кодировки есть варианты. Если же это ascii, то мы это всегда увидим. Кроме того, можно взять бинарный файл и вычленить из него строки. Для этого есть, например, команда strings.

В любом случае, лучше про ascii не забывать, и очередным подтверждением является то, что в юникоде каждый символ имеет имя, причём заглавными латинскими буквами.