Внимание: C декабря 2009 я начинаю вести блог на другом сайте — http://vlan.tumblr.com/. Пока что кажется, что Tumblr.com удобнее WordPress.com. Переезд моего блога пока временный: будем считать, что на зиму, а там посмотрим. Прошу вас подписаться на ленту новостей нового блога!

Есть разные претензии к setuptools (см. посты в блогах Brett Cannon и James Bennett), Здесь я кратко скажу о моих собственных. Во-первых, setuptools не создаёт промежуточные каталоги при setup.py install. Во-вторых, интерпретатор Python при старте сканирует слишком много файлов и каталогов. Возможно, это связано с форматом пакетов eggs модуля setuptools, хотя может и нет. Наконец, setuptools привносит дополнительную сложность по сравнению с distutils, а пользы от него — только в более простой установке скриптов, команде setup.py develop и описании зависимостей.

Все эти вещи можно сделать и без setuptools. Скрипты можно ставить обычным копированием с помощью distutils. Команду develop можно заменить созданием символьной ссылки из каталога в PYTHONPATH на каталог разработки.  В плане зависимостей интересна утилита pip, но пока что easy_install кажется удобнее.

#!/bin/sh

while true; do
    inotifywait -e MOVE_SELF,MODIFY,CLOSE_WRITE ../wiki/*.md img/*
    sleep 1
    make --quiet
done

Очень удобная штука!

Вопрос: насколько правильно при каждом сохранении выполнять анализ корректности программы/статьи? Можно смотреть на это так. Либо это заставляет больше стараться, чтобы при каждом сохранении иметь синтаксически корректную программу, либо добавляет ответственности при написании кода и упорядочивает мысли.

Для задач парсинга я написал библиотеку funcparserlib. Эта библиотека предназначена для создания парсеров по методу рекурсивного спуска на основе функциональных комбинаторов. Также я написал вводное руководство по funcparserlib (на английском), которое будет интересно всем, увлекающимся функциональным программированием (FP) и/или языком Python. Рекомендую его почитать!

Вот, например, такие картинки деревьев можно легко получать с помощью funcparserlib:

>>> print dotparser.pretty_parse_tree(tree)
Graph [id=g1, strict=False, type=digraph]
`-- stmts
    |-- Edge
    |   |-- nodes
    |   |   |-- n1
    |   |   |-- n2
    |   |   `-- SubGraph [id=n3]
    |   |       `-- stmts
    |   |           |-- Edge
    |   |           |   |-- nodes
    |   |           |   |   |-- nn1
    |   |           |   |   |-- nn2
    |   |           |   |   `-- nn3
    |   |           |   `-- attrs
    |   |           `-- Edge
    |   |               |-- nodes
    |   |               |   |-- nn3
    |   |               |   `-- nn1
    |   |               `-- attrs
    |   `-- attrs
    `-- Edge
        |-- nodes
        |   |-- SubGraph [id=n3]
        |   |   `-- stmts
        |   `-- n1
        `-- attrs

Итак, предлагаю взглянуть на руководство, а питонистам — попробовать funcparserlib, посмотреть другие доки и примеры на сайте библиотеки.

Отличительные особенности библиотеки funcparserlib:

• Несколько необходимых удобных комбинаторов парсеров (API всего 14 вызовов). Код получается компактным, очень похожим по языку на xBNF-грамматики
• Маленький размер самой библиотеки: всего лишь 0.5 KLOC с комментариями
• Обнаружение ошибок по методу длиннейшего разобранного префикса даёт разумные сообщения об ошибках разбора
• Маленький токенизатор на основе регулярных выражений позволяет следить за позицией лексем в тексте, выдавать её в сообщениях

При своём небольшом размере, библиотека является достаточной для написания парсеров весьма больших грамматик. Но главное предназначение — разбор небольших языков и языков DSL (предметно-ориентированных).

Для Python существуют несколько библиотек синтаксического анализа. Сравним некоторые из них с funcparserlib:

• pyparsing. Самая популярная библиотека. Имеет не очень большой размер кода (3.7 KLOC), очень избыточный разношёрстный API (около сотни вызовов), довольно медленная (по простым тестам в 3 раза медленнее, чем funcparserlib)
• LEPL. Библиотека с большой функциональностью, опциями и пр. (API содержит около сотни вызовов) Имеет очень большие для данной задачи исходные коды (около 15 KLOC). Быстрая, по утверждению авторов

Библиотека funcparserlib возникла поначалу из игрушечного примера парсера JSON, который я написал в 2008 году. Пример был создан, чтобы показать, что можно писать парсеры, в точности соответствующие формальной грамматике языка. Летом 2009 года я вернулся к парсерам на Python и решил дописать библиотеку, добавить токенизатор на regexps, выполнить оптимизации и т. д. На данный момент доступна версия 0.3.2, по которой я написал довольно много документации (на английском).

Теперь funcparserlib включает вполне приличный парсер JSON как один из примеров. Этот парсер поддерживает JSON со всеми нюансами и по скорости всего в 3 раза медленнее, чем специализированная библиотека simplejson. А исходного кода — в 8 раз меньше, намного более читаемого :)

Вот «иерархия» модулей, расширяющих функтор до монады. Полезные комментарии к соответствующим классам Haskell есть в статье The Typeclassopedia из The Monad.Reader.

module type FunctorType =
sig
  type 'a t
  val map : ('a -> 'b) -> 'a t -> 'b t
end

module type PointedType =
sig
  include FunctorType
  val pure : 'a -> 'a t
end

module type ApplicativeType =
sig
  include PointedType
  val (<*>) : ('a -> 'b) t -> 'a t -> 'b t
end

module type MonadType =
sig
  include ApplicativeType
  val join : 'a t t -> 'a t
  val (>>=) : 'a t -> ('a -> 'b t) -> 'b t
  val (>>) : 'a t -> 'b t -> 'b t
end

Здесь уже видно, что не всё получается как в Haskell. Сигнатуры модулей не позволяют привести значение терма по умолчанию.

Upd: Выложил полный исходник с примерами в pastebin.

Мы можем определить структуру модуля, соответствующего сигнатуре. Например, вот тип 'a option как монада:

module OptionMonad =
struct
  type 'a t = 'a option

  let map f x =
    match x with
      | Some x' -> Some (f x')
      | None -> None

  let pure x = Some x

  let (<*>) f x =
    match (f, x) with
      | (Some f', Some x') -> Some (f' x')
      | _ -> None

  let join x =
    match x with
      | Some x' -> x'
      | None -> None

  let (>>=) x f = join (pure f <*> x)
  let (>>) x y = x >>= fun _ -> y
end

Здесь пока что всё хорошо. Однако при использовании модуля возникают проблемы, т. к. ограничения на полиморфный код здесь вводятся явно, через параметризацию модулей (модуль с параметром является функцией из модуля в модуль и называется в OCaml функтором, не путать с классом Functor!).

Итак, вот простенький модуль, параметризованный классом монады, работающий со значениями типа 'a Monad.t:

module MakeSumInMonad (Monad : MonadType) =
struct
  let (>>=) = Monad.(>>=)
  let return = Monad.pure

  let maybe_div a b =
    match (a, b) with
      | (Some a', Some b') ->
        if b' = 0 then
          None
        else
          Some (a' / b')
      | _ -> None

  let (+) a b =
    a >>= fun a' ->
    b >>= fun b' ->
    return (Pervasives.(+) a' b')
end

Прежде чем работать с модулем, нужно создать его, применив наш параметризованный модуль-«функтор» к модулю со структурой монады:

module SumInMaybe = MakeSumInMonad (OptionMonad)

Это далеко не так приятно, как в Haskell. Там это выглядит более естественным. Здесь же приходится оборачивать любой код, работающий с типами некоторого класса, в технический модуль. Также я пока не смотрел, что будет с модулями с несколькими параметрами.

В конце небольшой тест:

let main () =
  let (/?) = SumInMaybe.maybe_div in
  let (+?) = SumInMaybe.(+) in
  begin
    assert ((Some 4) /? (Some 2) +? (Some 3) /? (Some 1) = (Some 5));
    assert ((Some 4) /? (Some 0) +? (Some 3) /? (Some 1) = None);
  end

Ниже рассказ об этом. Если вкратце, было весело! :)

Upd: В финальной таблице результатов мы заняли 95 место с 1826 очками.

Один из членов команды Jkff уже описал наше участие в своём отчёте, так что здесь я остановлюсь на частностях и личном впечатлении, а за общим описанием отсылаю вас в его блог.

Итак, описание Jkff вы уже прочитали. Я бы хотел рассказать про отдельные моменты конкурса. Мне наиболее интересно то, почему мы заняли относительно невысокое место (за 4 часа до окончания мы были 84-ые из 317). Поэтому ниже проводится «разбор полётов». Но я хочу сразу сказать, что мне лично было приятно участвовать с нашей командой! Мы хорошо сработались и я с удовольствием поучаствую в следующем году. Ниже я расскажу также о весёлых моментах в конкурсе :)

Задание

Итак, во время прочтения задания мы сразу и обрадовались, и обеспокоились :) Я, в общем-то, правильно предсказал то, что нас ждёт. До конкурса на каналах Jabber и IRC много говорилось об аэрокосмической теме и о времени 13:00:16. Окончательно раскусить оргов так и не смогли. Мне было ясно следующее: форматы времени и вообще точное время будут играть большую роль (про важность дискретного времени мы вспомнили, к сожалению, слишком поздно). Другой моей догадкой была очередная виртуальная машина (VM), которая обеспечит независимость от платформы: орги слишком уклончиво отвечали на вопрос о том, как надо было отправлять результаты.

В самом начале конкурса выяснилось, что 1995-06-29T13:00:16 (часовой пояс?) — это время первой стыковки шаттла и станции «Мир». Управлять спутниками — это звучало весело :) Но мы сразу стали опасаться сложностей с VM: Jkff вычитал что-то про машинные инструкции, записывающие результат в память по адресу инструкции, и мы стали думать про самомодифицирующийся код и пр. В реальности всё оказалось очень просто. VM была с гарвардской архитектурой: память команд и данных у неё была раздельная. К тому же позднее нам стало понятно, что платформонезависимость была единственной целью включения VM в задание. Способ и эффективность реализации VM на решение почти что не влияли. Мы же напрасно уделили этому внимание, в тактике нашей команды постепенно начала накапливаться ошибка подхода к заданию.

Интерфейс ctl-sim

Почти с самого начала мы стали решать задачу в духе Unix. Вырисовывалась пара взаимодействующих программ: sim — симулятор, выполняемый на VM, и ctl — контроллер, ведущий симулируемый спутник. В ходе небольшого обсуждения я изложил своё видение взаимодействия этой пары. ctl и sim будут обмениваться командами чтения/записи в порты IO через неименованные каналы ОС. Формат обмена FMT было решено сделать текстовым, что давало нам читаемый и отлаживаемый интерфейс в стиле Unix. Например, имея готовую трассу команд на вход симулятора, вывод можно было, в принципе, увидеть картинку полёта спутников следующим образом:

$ cat trace.fmt | sim | vis

В таком же стиле можно было вручную вести спутник (номеров портов было мало и мы помнили их наизусть):

$ sim
0 0x3e80=1002
0 0x0=0 0x1=10000 0x2=-6352278.930 0x3=6361717.566 0x4=21082000
1
1 0x0=0 0x1=10000 0x2=-6347554.360 0x3=6366431.626 0x4=21082000
2 0x2=5000
2 0x0=0 0x1=5000 0x2=-6345326.291 0x3=6371142.177 0x4=21082000

По общему мнению, интерфейс взаимодействия контроллеров и симуляторов получился хороший, он позволил нам писать их на разных языках: Python, Haskell, C++ и Java (на ней был написан визуализатор). Однако сразу же надо высказаться критически об этом интерфейсе. Он способствовал написанию контроллеров на разных языках, что уменьшало шансы совместной работы над кодом и повторного использования кода в следующих задачах. Мы обезопасили себя от проблем с отладкой VM, нашего физического эмулятора и разных контроллеров. Однако это дало начало ненужному в таком коротком конкурсе языковому разброду. К тому же отладка интерфейса обошлась нам в 4 человеко-часа. Но в целом, всё же, интерфейс был положительным моментом.

С упомянутой отладкой интерфейса отдельная история. Несмотря на то, что программы взаимодействовали через каналы (pipes), они были крайне сильно связаны. Контроллер ожидал ответа от симулятора после каждой своей команды. Фактически, это был протокол с обменом сообщениями «запрос-ответ». А для этого только каналов недостаточно, нужно организовать подчиенение процессов. Эта типичная схема описана у Реймонда в “The Art of Unix Programming”. Мы решили оставить всё на каналах и просто сделать программу-драйвер fmtdump, которая связывала каналы двух программ крест-на-крест и заодно писала логи их взаимодействия в общем формате FMT. Всё бы хорошо, да только мы не задумывались над обязательностью flush(2) после write(2) и над тем, что строки текствого протокола мы не имеем права буферизовать при чтении: строку неизвестной длины без блокировки можно читать только по одному байту за раз.

После того, как минут за 30 всё это было осознано, началась борьба по отключению буферизации ввода во всех языках, на которых писались контроллеры. В Python это оказалось сделать на удивление сложно. Способ, описанный в документации, не работал и одно время мне пришлось использовать свою функцию чтения строки по байту. Позже правильный способ всё-таки был найден: открыть файл в бинарном режиме, указать размер буфера 0 и читать строку через readline, а не итерироваться по строкам файла. В других вариантах буферизация всё равно происходит.

Вот с этими техническими деталями VM и интерфейса симулятора к контроллеру мы провозились до середины субботы. Сама VM получилась тоже интересно, см. блог Jkff. Напомню, что для получения симулятора использовалось взаимодействие языков байткода VM, Python, Haskell и C++.

Все пишут контроллеры

Закопавшись с VM, мы сели за саму задачу, т. е. за контроллеры, только к полудню субботы. До этого я писал транслятор байткода в Haskell-ассемблер VM, а также драйвер пары контроллер-симулятор fmtdump, Kerzum писал компилятор sim с Haskell-ассемблера в C++, Jkff писал визуализацию выходного лога в формате FMT, а Cfr и Incubos писали альтернативный sim, моделирующий мир по формулам из задания.

Cfr уже без Incubos (который пошёл спать) начал писать свой контроллер на Haskell, однако скоро от его кода ответвился Kerzum, который решил попробовать свою реализацию. Параллельно Jkff начал ещё один контроллер на Python. Я занимался скриптами сборки всех проектов и небольшими исправлениями к fmtdump. Не очень понятно, что мешало всем вместе вначале решить задачу математически и алгоритмически. Наверное, всем просто хотелось уже наконец попробовать подойти к задачам практически: симулятор и драйвер были как раз готовы. Начавшееся разделение хаскеловских и питоновских контроллеров в результате затормозит нас на довольно большое время, хотя и обезопасит от отдельных неудач с конкретными контроллерами. Как и в случае с интерфейсом контроллер-симулятор, мы опять подошли к проблеме слишком защищёно.

Вечером в субботу свой контроллер начал и Incubos, взяв за основу мои наброски (об этом речь ниже). Так что в воскресенье практически все работали над контроллерами, но своими, а не общим. Знания тоже локализовались в коде и обмен ими шёл не особо эффективно.

Эволюция контроллеров на Python

После того, как к полудню субботы я решил вопросы с драйвером, я взялся за контроллеры. Однако вместо того, чтобы познакомиться наконец детально с физикой задачи (а не только с VM и форматами), я решил придумать хороший интерфейс контроллеров на Python, чтобы их было легко писать и комбинировать.

Утром я написал для ребят простой парсер формата FMT на Python и дёрнул меня тогда чёрт сделать его интерфейс потоковым! Возможно, это была главная моя ошибка за весь конкурс. Контроллер представлялся в этом первом интерфейсе функцией типа Iterable(Ports) -> Iterable(Ports). Чуть позже, думая об универсальном интерфейсе, я написал вспомогательную функцию buffered :: ([Ports] -> Ports), int -> (Iterable(Ports) -> Iterable(Ports)), которая позволяла работать с одним шагом симуляции, но иметь буфер портов за предыдущие ходы. Тогда мне показалось, что такая потоковая обработка наряду с буферизацией будет удобной для решения всех задач. Но я почему-то забыл с самого начала подумать про суть обмена данными с симулятором и про композицию алгоритмов управления в контроллерах. С таким интерфейсом это получалось крайне неестественно.

Что же было естественным способом управления симулятором? Старое доброе ООП. Наша задача сводится к синхронному обмену сообщениями (message passing) между процессами с локальным изменяемым состоянием.

К сожалению, Jkff и Incubos уже вовсю писали свой код на потоковом интерфейсе (код Incubos особенно критично зависел от этого), а ОО-интерфейс я придумал только днём в воскресенье, после того, как, наконец, выспался после 36-часового бодрствования.

Новый интерфейс заключался вот в чём. Есть интерфейс ООП Sim с единственными методом: interact :: Ports -> Ports, который в ответ на управляющие сигналы в порты ввода выдаёт сигналы портов вывода. Всё очень банально! Зато сразу стало возможно делать следующие вещи: объединять контроллеры (процедуры аргумента Sim) последовательной композицией, организовывать внутри них конечные автоматы, вызывать внутри контроллеров другие контроллеры (вложенные конечные автоматы), делать классы-прокси для дампа логов взаимодействия, запускать альтернативный симулятор внутри процесса для предсказания физики и пр.

Посетила бы нас эта простая мысль раньше — наш код был бы повторно используемым, более выразительным и наверняка содержал бы меньше ошибок.

Последнее улучшение интерфейса контроллера состояло в том, что специальный прокси TraceSim добавлял поле trace :: [(Ports, Ports)] с историей команд ввода-вывода, что нужно почти всем алгоритмам.

Физика и геометрия

Отдельной темой стоят наши обсуждения физики и геометрии задачи. К сожалению, в субботу их было очень мало, но зато они были интересные :) и в воскресенье они позволили нам прийти, фактически, к решению задачи. Особенно эффективными мне показались обсуждения физики у доски, в которых участвовали я, Jkff и пару раз Cfr с Kerzum. На мой взгляд, примерно так и стоило бы решать задачу: обсуждать и вместе писать алгоритмы, а не распределять усилия на несвязанный код. Хоть в итоге именно распределение позволило набрать нам наши очки, но оно и помешало набрать нам больше.

Надо заметить, что ещё в субботу вечером у нас был код, выводящий спутники первых задач на нужную орбиту, но нам упорно не давали очков. Оказалось, мы невнимательно читали задание, допустили несколько опечаток в расчётах, выводили данные со значительной потерей точности, также совсем забыли, что мы летаем в дискретном времени с шагом 1 сек и скоростью порядка 10 км/сек. Это значит, что без учёта дискретизации (например, параллельным расчётом по непрерывной формуле и дискретной симуляцией с коррекцией после этого) мы не могли достичь нужной точности в орбитальных переходах.

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

Причины неуспеха

По моему мнению, нам помешало следующее:

• Не пытались писать алгоритмы контроллеров вместе
• Не провели своевременный поиск доков по предметной области
• Долго не вспоминали о дискретном времени
• Писали код на разных языках, не думали о композиции алгоритмов
• Потеряли полдня на баг с выводом неточных чисел с плавающей точкой
• Плохо организовали математический код, допускали много опечаток

Что мне понравилось

Ну и после такого анализа хочу поделиться приятными впечатлениями :) Вот что было интересно:

• Мы запрограммили классный многоязыковой процесс получения симулятора
• Картинка concept map на доске в самом начале позволила быстро найти связи, которые ещё никто не понимал
• Unix-интерфейсы рулят! Мы игрались с интерфейсом ctl-sim, рисуя бешеные трассы, отлавливая баги во взаимодействии: всё было текстовым и простым
• Мы выпили в ходе обсуждения в первую ночь кучу кофе и продержались где-то до 20 часов субботы
• У нас были интересные обсуждения у доски. Было здорово подсказывать, ловить баги друг друга, придумывать новые подходы :)
• Система управления версиями Mercurial всё время рулила
• Мы хотели и продумывали (но так и не сделали) интерактивный контроллер в визуализаторе, чтобы играться в спутник с клавиатуры

Цифры

Ну и совсем под конец несколько цифр:

• 219 ревизий в Mercurial
• 11 исполняемых программ
• 1701 строка на Python, 630 на C++, 475 на Java, 460 на Haskell, 171 на C, 111 на make, 67 на sh
• На момент заморозки таблицы 84 место, 1654 очка (до отправки последних результатов)

Спасибо членам команды за классно проведённое время! :)

Наша группа объединяет людей по интересу к Arch Linux и связанным технологиям, желающих делиться информацией, вместе обсуждать темы, решать встречающиеся сложности, и просто встречаться ради общения. Если вам интересно, заходите на сайт нашей группы, присоединяйтесь к списку рассылки email.

Arch Linux — это действительно симпатичная система, близкая духу Unix. Вот что говорят пользователи этой системы о пути Arch. В основу дистрибутива положены:

• Простота и элегантность базовой структуры системы
• Корректность кода вместо видимого удобства для пользователя
• Открытость
• Направленность на пользователя в смысле возможности полного контроля над системой
• Свобода выбора компонентов и других вещей в своей системе

Хорошие и полезные качества, свойственные минималистичному простому софту.

Upd: Оставил аккаунт для общения с теми, кто не хочет или не может общаться по-другому :)

Этот сайт слишком централизованный, т. к. люди вынуждены использовать его для общения, даже если они хотели бы общаться в другом месте. Это происходит из-за огромного количества пользователей сайта (на настоящий момент около 30 млн.). Сайт как воронка притягивает новых пользователей за счёт уже имеющихся. Я считаю это неприемлемым, т. к. это ненадёжно и небезопасно. Если с сайтом технически или административно что-то произойдёт, все эти люди окажутся без сервиса. Речь даже не о выходе из строя, а о таких мелочах, как реклама, плата за дополнительные функции и т. д.

Сайт ВКонтакте также слишком закрытый. На нём 30 млн. страниц пользователей, сотни миллионов фотографий, статусы присутствия, записи в заметках, записи статуса… Догадайтесь, сколько страниц этот сервис внёс во Всемирный Веб? Миллионы? Нет! Целых 5 страниц: начальную, регистрация, пользовательское соглашение и реклама. Это не социальная сеть, а социальная чёрная дыра.

Может, стоит заметить, что другие подобные сайты типа Одноклассников, Facebook и пр. такие же плохие. Даже LiveJournal немного плох, но только тем, что там есть сеть друзей и стало слишком много рекламы.

Как, на мой взгляд, должна выглядеть социальная сеть в Вебе?

Каждый человек должен иметь адрес email и мгновенных сообщений Jabber (в отличие от ICQ и других протокол Jabber XMPP является открытым стандартом Интернета). Через эти средства можно связываться друг с другом напрямую (Peer to Peer) без централизованных серверов. Это заменяет сообщения ВКонтакте, а также информацию о присутствии онлайн.

Каждый человек должен иметь домашнюю страницу. Не важно где: на сайте со своим блогом, на бесплатном хостинге — лишь бы она была доступна для всех в Вебе по её URL. На этой странице можно привести фотографию, краткую информацию о себе, контактные данные, ссылки на другие свои сайты. Можно завести список со ссылками на страницы друзей. Это заменяет страницы пользователей ВКонтакте и списки друзей. А находить друг друга можно легко при помощи Яндекса, Google и других поисковиков.

Каждый человек может иметь блог. В нём он может писать о своих мыслях, событиях, информировать других об интересных вещах. Другие люди могут оставлять комментарии к записям, могут подписываться на ленты обновлений Atom и RSS. Можно также завести микроблог, в который пишут обычно по одному предложению, но часто, чтобы держать других в курсе своих повседневных дел. Это заменяет заметки ВКонтакте, комментарии и стену.

Хочу отдельно сказать о важности новостных лент Atom и RSS. Благодаря стандартному формату ленты можно подписаться на кучу лент друзей и разных других сайтов при помощи программы чтения лент новостей. Такая программа-агрегатор лент сама будет забирать обновления с сайтов, так что все ленты друзей можно читать как одну объединённую. Программ для чтения лент новостей существует много. Есть и для своего компьютера, и веб-сервисы типа Google Reader. Это заменяет ленту обновлений друзей ВКонтакте.

Все эти сервисы: свой email, свой адрес Jabber, свою домашнюю страницу, свой блог — каждый может выбрать на одном из бесплатных сервисов-хостингов независимо от друзей и приятелей. И тем не менее, все смогут общаться друг с другом, при желании меняя сервисы на другие и не беспокоя друзей вступлением в новые социальные чёрные дыры.

Ещё раз подчеркну преимущества такого подхода: децентрализация, доступная всем информация, открытые стандарты, простота использования и техническая простота, отсутствие привязанности к одному поставщику сервиса.

В осеннем семестре 2008 читал в Политехе курс лекций «Языки программирования» студентам 5-ого курса кафедры АиВТ. Идеей было дать общий подход к рассмотрению языков, познакомить с функциональным программированием, рассмотреть некоторые компромиссы при проектировании языков. Курс наполовину основан на SICP и языке Scheme, а вторая половина посвящена сравнительному обзору языков C, C++, Python и Java.

Поделюсь впечатлениями о курсе. Во-первых, наши студенты имеют весьма туманные навыки программирования, немного грустно :( Думаю, такое характерно для большинства вузов, хотя наверняка есть и исключения. Они написали к 5-ому курсу слишком мало программ (к тому же весьма простых), и не в состоянии нормально чувствовать и рассуждать о проблемах борьбы со сложностью в программировании. Во-вторых, в курсе получился большой перекос в сторону основ ФП и Scheme в противовес передаче сообщений, параллельности, малым языкам и т. д. Наконец, чтение курса помогает заострить внимание на моментах, которые иначе не были бы замечены и систематизированы.

Теперь есть мысли о нескольких лекциях или семинарах по сетевому и распределённому программированию. Кажется, уже достаточно много важных и интересных вещей могу сказать по этому поводу.

Студентов поздравляю с Татьяниным днём :)