Обсуждение

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

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

Я понял - как раз потому и решил обратить внимание на другой подход к вопросу, тем более, что сейчас ФП довольно быстро превращается в мэйнстрим. Там идея такая - переменных и изменямых состояний вообще нет. Программа - по сути одна большая формула, а выполнение состоит в вычислении ее значения. Понятно, что на самом деле время там присутствует - но как зависимость значения функции от ее аргументов. Скажем в Clean чисто императивная часть (работа с файлами etc) делается так: есть тип World - "состояние мира", функции, которые его модифицируют получают его параметром и выдают в качестве результата (система типов гарантирует невозможность "копирования" World и ему подобных) - функция открытия файла "вытаскивает" из World значение типа File, возвращая пару (File, World), а функция close наоборот "вливает" значение типа File в World. Выполнение состоит в вычислении значения функции с именем start, которой передается "начальный" World. Что тут действительно нетривиально - это не фикция - вычисления инициируются действительно "от хвоста" - скажем если не написать close, то файл вообще не будет создан - потому что состояние World от него не зависит. В Haskell подход несколько другой, но суть таже самая. Сделано это от того, что в денвых языках реальный порядок вычислений оказывается довольно противоестественным и труднопредсказуемым - поэтому сделать все зависимости явными - практически единственный возможный выход, но заодно достигается много других интересных вещей - во-первых - резко сокращается количество зависимостей. во-вторых - в отсуствие неявных зависимостей вопрос с распараллеливанием уходит на уровень не меняющей семантику оптимизации - хотя активно, кажется, никто этим не занимался.

Есть, кстати, подарочное соединение FP и массово-параллельности в лице Erlang. Популярность коего постепенно растёт.

В Mozart/Oz есть всё то же, что есть в Эрланге, и многое многое другое, и собрано вместе оно гораздо красивее.

... Ликвидация последствий решения проблемы 2000 года ...

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

Вы не обратили внимания: я нигде не писал про "планирование проектов" -- в этой области есть устоявшаяся терминология (project management, управление проектами). "Планирование работ" -- это совсем другое. Извините, но текст я писал для людей, которые понимают принципиальную разницу между workflow (ключевые слова BPEL и APS)и work breakdown structure (ключевые слова Gantt и CCPM). Когда же я говорю о программистской части, то я опираюсь на основные положения, разработанные в свое время группой "Аттик" мехмата МГУ (я провел пару лет в аудитории 1310 ГЗ МГУ и имел удовольствие работать с Кушниренко, Лебедевым, Варсановьевым, Дымченко, Эпиктетовым, Леоновым и т.д.). Как и что называть в программировании и что вообще считать программированием -- так тут у меня свое собственное мнение есть, и мне все равно, что вы слышали. Я за свою жизнь про это многого наслушался, а много чего и был свидетелем (я свою первую программу написал в 1975 году, а первое место моей работы было -- исследовательский ВЦ в университете). Так что с удовольствием получу от вас комментарии по существу вопроса, а не по используемой терминологии. Скажем, чему в параллельных программах соответствуют "типовые кусочки проекта", а чему "шаблоны проекта"? Про workflow я этого не спрашиваю: там стремительно побеждают именно языки программирования (хотя и не слишком процедурные). А "чисто программистский взгляд на проблему" тут меня мало волнует: Алан Кей совершенно не зря говорит, что у современных программистов глаз абсолютно замылен.

Тут нужно смотреть в совершенно другую сторону: совместимость языкового представления с типовыми операциями, которыми люди планируют свои коллективные дела. Скажем, вы организуете вечеринку: удобно ли вам будет написать ее план на функциональном языке, а затем раздать этот план приглашенным? Или приглашенным для чтения этого плана требуется резко изменить их способ представления мира? Там ведь еще и много вопросов, почти никак не зависящих от языка. Скажем, как представлять в самой программе ее же ветки из системы версионирования? Ведь система версионирования -- это тоже такая специальная программа (с "непосредственным исполнением", это третий по сравнению с компиляцией и интерпретацией режим исполнения -- например, когда вы курсор гоняете стрелочками по экрану, запуская примитивы перемещения курсора) по порождению целевой программы. Знаменитое дюновское "планы внутри планов внутри планов" ;) Так что я менее всего ожидаю, что речь зайдет о функциональном программировании. Но Алан Кей говорит, что в Лиспе самым важным была метасистема -- и в SmallTalk она была важна, и даже в Squeak. Вот эта метасистема наверняка будет важна и в этом новом "управлении деятельностью" (как смене "управления проектами/программами", "управления процессами" и даже "управления проблемами" (issue management)).

Ну, распечатку из системы управления проектами я как-то смогу отдать прорабу на стройке, чтобы он выполнил свою часть. А можно ли это сделать с программой на Mozart/Oz? К тому же меня очень волнуют проблемы версионирования в такой программе (она переписывается в тот момент, когда обнаружились трудности с исполнением). Что, версионирование описываем в терминах этого же подхода (это же "программирование программы как объекта") или переходим на язык git\bitkeeper\svn\cvs? И что там с режимом "непосредственного исполнения" (см. чуть ниже http://ailev.livejournal.com/460198.html?thread=3428262#t3428262)?

Меня честно говоря не волнуют ваши регалии - они заведомо лучше моих. И я уж точно не собираюсь стыковать термины из терминологий управления и параллельного программирования (просто мне проектирование, менеджмент, управление и т.д. скучны, и знаний у меня в этих областях никаких - например, чем типовые кусочки отличаются от шаблонов, я понятия не имею). Моё внимание привлёк тот факт, что Алан Кей несёт полную чушь по целому ряду вещей и ведёт из них далеко идущие выводы, а вы на этой основе тоже проводите ряд аналогий, которые от компьютеров к организациям иногда возможно и работают, но от организаций к компьютерам до абсурда натянуты (антропоцентричны?). Можно сколько угодно говорить, что у программистов взгляд замылен и искать им новые парадигмы, но программистам это вряд ли поможет (исходя из последних тридцати лет прогресса в CS). А помогут им реальные знания, алгоритмы и системы автоматизации параллельной работы над структурами данных (MapReduce, алгоритмы из OpenMP и SWARM, более лёгкая и интегрированная лексика для запуска тредов (нитей?) и описания их расхождения, схождения и пайплайнинга, понимание того, как работает память и кэш между многими процессорами).

Я не делаю выводов на основе того, что говорит Алан Кей. Я делаю собственные выводы, и отмечаю, что мои собственные мысли оказались схожи с мыслями Алана Кея. Мне было приятно это обнаружить. Я думаю, что когда-нибудь вам станет интересно, как работают люди, а не "железо". В этот момент, возможно, вы вернетесь к этому постингу и попытаетесь понять, о чем он. Да, именно об антропоцентричности (с последующим обсуждением антропности программистов ;)

Может быть, я вполне за :) CS всегда идёт более человеческое лицо, и лингвисты с HCIерами медленно, но верно в ту сторону толкают. (Кстати, для вашего материала наверно уместнее сказать "социоцентричность", а не "антропоцентричность".) Но чушь остаётся чушью. Скажем (продолжая начатый вами разбор терминологии), термин "версионирование" тоже имеет совершенно чёткое определение в программировании, и я совершенно не пойму, правильно ли вы его используете, и если да, то что вы имеете в виду.

1. Антропный принцип в философии подразумевает человека в его связи с другими людьми, а не просто "биологическое подобие". Тем более, что "социоцентричность" указывает на общество, как на объект, а мне это точно не нужно. Я бы предпочел говорить о центрировании на (человеческой) деятельности, причем меня более всего волнует организация деятельности. 2. Когда я говорю о системах версионирования, то я имею ввиду всяческие варианты git/bitkeeper/svn/cvs и так далее. Когда люди пытаются писать большой проект (десятки тысяч работ: строительство какой-нибудь подстанции с монтажом оборудования), то неминуемо возникают ветки, только одна их которых идет в дело. По сути, версионирование в программах -- это предпредрантайм, когда выбирается одна из веток (в рантайме это было бы просто "ветвление", а предрантайм -- это компиляция, билдтайм). Мне этот момент существования разных экземпляров программы (вместо существования двух ветвей, из которых одна выбирается по какому-то условию) представляется чрезвычайно любопытным. Тем самым я рассматриваю текст "большой программы" (все ветки в системе версионирования), которые идут на исполнение -- но действительно исполняются только некоторые команды (часть отсекается на уровне ветки в самой системе, часть при условной компиляции и оптимизации, часть при обработке условий ветвления в ходе исполнения). Меня очень бы интересовала связная модель в этой области. По сути, кроме компиляции и интерпретации существует "непосредственное исполнение" (вставка в программы такого режима когда-то в группе "Аттик" называлась "левенчугизация" -- скажем, в редакторе текстов курсор когда-то двигался командами, это был "строчный редактор". Передвигать курсор непосредственно стрелочками с клавиатуры -- это и есть "левенчугизация" редактора текстов :), и мне кажется, что для обсуждения версионирования полезно будет вспомнить о теоретической разнице между этими всеми режимами и ввести разнообразие исполнителей (тот, кто выбирает ветку в системе версионирования -- это ведь тоже исполнитель, но он не исполняет программу, он отрабатывает "программу git/bitkeeper/svn/cvs" в режиме непосредственного исполнения).

Ничего плохого в том, что любой математик сначала осваивает арифметику, биолог - классификацию, нет.

Тем самым я рассматриваю текст "большой программы" (все ветки в системе версионирования) Часто ли в вашей практике встречались программы, для которых имело бы смысл поддерживать больше двух ветвей?

Все зависит от того, как вы понимаете границы программы (сколько у вас "отдельных программ, хотя и связанных") и сколько независимых групп разработчиков у вас пытаются работать над похожими, но разными проблемами.

Я об этом и спрашиваю.

ОК. Тогда отвечу: когда вы сверстываете единый бюджет (подразумевающий план действий) для 6000 человек, то у вас есть очень много конкурирующих вариантов и довольно много лоббирующих групп. Поэтому веток не просто больше двух, а существенно больше двух (смело можно считать, что каждая крупная служба, а их от 7 до 20, будет иметь свою ветку). Я еще раз обращаю внимание, что "чисто программистские задачи" меня волнуют мало, и в системе версионирования я не собираюсь хранить коды софтовых проектов на 50000 строк.

Меня сбили с толку слова типа компиляции, рантайма и прочего. В бюджете такое количество веток обосновано. Если говорить о системе документов, то самое интересное - это проверка валидности выбранной конфигурации. С компьютерными программами попроще. PS. Попытался представить себе merge двух файлов MS Project, ой...

Когда вы компилируете (лингво: compile=собирать материал, накапливать, составлять книгу) бюджет и соответствующие обоснования, то тем самым вы собираете программы работ. То есть это время планирования и бюджетирования (время компиляции в буквальном смысле слова). А рантайм -- бюджет пошел на исполнение (run -- бег, пробег, прогон и т.д.), планы выполняются, деньги тратятся. Использование английского языка исключительно как "спецпрограммистского" совершенно сбивает с толку, не так ли? Если бы мы беседовали на английском, то никакого непонимания бы не было: это все я пишу про одно и то же, что про программирование, что про производство. Меня как раз интересует схожесть паттернов организации. Про ветки бюджета я не слышал, слышал про "варианты". Интересно, что было бы, если бы в системах версионирования ветки называли бы "вариантами" -- вполне возможно, тогда эта концепция пошла бы в нормальную жизнь (еще после пары-тройки таких же упрощающих лексических замен). Ибо в нормальной жизни варианты есть, а деревья корнями вверх или вбок -- не растут.