October 24th, 2010

2019

Неожиданность: питон тормознутей JavaScript

Случайно залез на пузомерку скорости языков (http://shootout.alioth.debian.org/), и обнаружил чудовищную тормознутость Питона -- даже по сравнению с JavaScript. Вот пример (включая Factor, который еще в эту пузомерку не успели подсунуть штатно -- http://factor-language.blogspot.com/2010/05/comparing-factors-performance-against.html):

FactorLuaJITSBCL V8 CPython
fasta 2.597s1.689s2.105s3.948s 35.234s
reverse-complement2.377s1.764s2.955s3.884s 1.669s
nbody 0.393s0.604s0.402s4.569s 37.086s
binary-trees 1.764s6.295s1.349s2.119s 19.886s
spectral-norm 1.377s1.358s2.229s12.227s1m44.675s
regex-dna 0.990sN/A 0.973s0.166s 0.874s
knucleotide 1.820s0.573s0.766s1.876s 1.805s


Тормознутей (и то не очень) только Ruby и SmallTalk. Что, Питон действительно очень высокоуровневый язык? Тогда почему объем его кода вполне сравним со всеми конкурентами (пузомерка и объем кода позволяет поглядеть, не только скорость), а не в разы короче? Или я что-то существенно не понимаю?
2019

Об образование: оценки времени

Предположим, что у нас на входе люди с каким-то высшим образованием (в котором была предусмотрена какая-то математика и естественнонаучная картина мира: физики-химики, инженеры и т.д., но не историки, литераторы или юристы), а на выходе нужно получить системных инженеров. Какие при этом существуют трудности? Закрою глаза на то, что в 2007г. много об этом писал, и попробую порассуждать снова:

1. Профессиональная переподготовка подразумевает по десятилетней давности нормам 1000 часов трудоемкости (http://www.russianenic.ru/rf/2.html -- Нормативный срок прохождения профессиональной переподготовки специалистов для выполнения нового вида профессиональной деятельности должен составлять свыше 500 часов аудиторных занятий. Нормативный срок прохождения профессиональной переподготовки для получения специалистами дополнительной квалификации должен соcтавлять не менее 1000 часов трудоемкости).

Эту цифру можно смело уполовинить, подразумевая "выполнение домашних заданий". Действительно, оставим 500 часов вдумчивого чтения и 500 часов решения задач -- абсолютно нереальная пропорция, но "все так делают".

Часовая лекция -- это при нормальной скорости 120 русских слов в минуту и 7.2 букв (плюс пробел -- 8.2) на русскоязычное слово -- 120*8.2*60=60Кзнаков с пробелами. Плюс картинки.

2. Но читать лекции сегодня уже несовременно, а современно работать над созданием Tech Packs (новомодное изобретение ACM -- группе редакторов собрать по самым модным темам правильные учебники, статьи, видео и т.д. и опубликовать "рекомендованным к изучению пакетом". Подробности Гуглем пока найти трудно, но см., например, тут).

Предположим, что часовая самостоятельная работа по письменному тексту 60Кзнаков будет такой же продолжительности, как прослушивание часовой лекции. Это крайне сильное предположение, но нас это не остановит. Более того, предположим, что все наши Tech Packs будут прорабатываться от корки до корки, причем это и будут "лекции". То, что нужно хотя бы 5% от общего содержания этих Packs зарезервировать под объяснения, как все эти тексты связаны между собой в общую картину мира, я пока умалчиваю.

Содержание книжек (или эквивалентных им по объему видеозаписей, статей, презентаций, документации к программам и т.д.) считаем ортогональным друг другу -- т.е. неповторяющимся.

3. 500 часов * 60Кзнаков = 30 000Кзнаков. Пусть наш TechPac состоит из не слишком толстых (но и не игрушечно тонких) томов по 1000Кзнаков (исключительно для удобства счёта).

Тем самым второе высшее образование по сегодняшним российским нормам -- это проработка (прочтение и столько же времени на решение задачи/ответы на вопросы) 30 не слишком толстых книжек, разве что тщательно подобранных.

Каждая книжка читается за примерно 17 часов, и еще столько же уходит на попытки употребить ее содержимое (решить задачи, ответить на вопросы, сделать проект).

4. Предположим, что на учёбу в день честно тратится 5 часов, а выходные -- это выходные. И один день в месяц разгрузочный. Это будет 5часов*20дней -- сто часов в месяц. Тогда 1000 часов будут освоены за 10 месяцев.

5. 1000 часов -- это 10% от того, что нужно для достижения мастерства (известная максима "в любой деятельности любой человек достигает мастерства за 10тыс. часов", например, п.2 из http://www.rb.ru/inform/112697.html). Ежели потом трудиться по новой специальности по 10 часов в день пятидневную неделю (200 часов в месяц), то оставшиеся 9000 часов можно набрать за 45 месяцев.

Итого: 55месяцев (4года 7 месяцев без отпусков) -- и можно рассчитывать на мастерство в новой специальности. При этом за эти почти 5 лет поколение технологий существенно меняется, но постоянное переучивание-доучивание в расчет не берем.

Это я продолжаю вялые размышления на тему программы общего верхнего образования (http://ailev.livejournal.com/853399.html) и обосновательных тезисов к ней (http://ailev.livejournal.com/855472.html). Можно, кстати, грубо оценить объем тамошней программы -- там 61 пункт, который примерно соответствует книжке. Пару лет -- и ключик к новой жизни у вас в кармане (с учетом того, что это будет "галопом по европам", "проходить мимо").

Теперь я думаю про наши консалтинговые проекты, и становится совершенно понятно, почему они идут так трудно и больно: специалистов по новейшим технологиям нет, а быстро получить такого специалиста нельзя -- даже если отрядить на проект людей full time, потребуется несколько месяцев на продуктивное вхождение в курс дела. И входить в курс дела придется не путём чтения книжек (никто этого не позволит, даже если это будет самое оптимальное), а путём попыток решать конкретные производственные задачи.

К этому всему нужно добавить, что материал современных учебников, а тем более статей (помним про Tech Pack!) без соответствующих инструментов (приборов, имитационных моделей, компиляторов DSL, САПР, программ управления проектами, станков, контроллеров и т.д.) освоить нельзя. А на производстве получить эти инструменты -- отдельная задача (необходимость всего этого инструментария должны понять еще необученные будущие специалисты, а потом "пробить" покупку у своего начальства).

Но ведь консалтинг на то и консалтинг, чтобы решать образовательные задачи в не предназначенных для образования местах за не предназначенное для образования время. Сюда и нужно думать.
2019

Программирование и моделирование таки объединяются. На очереди онтологизирование.

Интересная презентация Markus Voelter и Bernhard Merkle про то, как language workbenches стирают границы между программированием и моделированием-на-DSL -- http://www.dsmforum.org/events/DSM10/Papers/Voelter.pdf (есть и слайды, но они очень красочны и в разы менее понятны: http://www.dsmforum.org/events/DSM10/Slides/2.0930.Voelter.pdf).

Для меня ничего особо нового в этой статье нет (я уже несколько лет сформулировал этот тезис про слияние программирования, моделирования и онтологизирования). Но нужно обратить внимание на предложенное перечисление способов интеграции подъязыков модульной мульти-языковой системы (referencing, cascading, extension, embedding, annotation, cross-cutting by translation), и сами рассуждения про языковую модульность -- где знания предметной области реализуются в соответствующем языковом модуле.

Конечно, все эти идеи носятся в воздухе, только названия меняются. Так, отсутствие токенизаторов и визиторов в парсинге -- это уже общее место. Предложенное понимание cascading очень похоже на chains of meaning из FONC. Технология language workbench стремительно оформляется.

Осталось объявить, что онтологизирование нужно слить с программированием и моделированием. К этому тоже уже подходят. Так, в программе того же семинара по domain specific modeling, на котором выступали Voelter и Merkle, есть и доклад про онтологии в строительстве DSL -- http://www.dsmforum.org/events/DSM10/Papers/Gailly.pdf, где "We defined the notion of domain-specific quality as a component of semantic quality that depends on the satisfaction of the invariant conditions that define the domain of interest. These conditions should hold for all conceptual schemas that represent phenomena belonging to that domain". Конечно, там всё про UML и OCL, но есть и ссылки на OWL-реализацию.

Мы пойдем именно этим путём, и доведем его до логического (pun intended) конца.

P.S. Кого интересует, о чем еще говорилось на неделю назад закончившемся семинаре по DSM, загляните сюда: http://www.dsmforum.org/events/DSM10/ (все papers и слайды).
2019

REA (ресурсы, события, агенты): бухгалтерская и экономическая онтология

REA (resources, events, agents) -- онтология для бухучета и экономики, закрепленная в ISO/IEC 15944-4:2006 (Open-edi, http://workspace.infoman.ca/sc32_wg1/images/8/8d/SC32WG1_N0317_FDIS-15944-4-final.pdf) и UN/CEFACT как модуль бухгалтерско-экономической специализации для UMM (UN/CEFACT Modeling Methodology, http://umm-dev.org/, все очень знакомо: профили UML).

Несколько наборов ссылок: http://en.wikipedia.org/wiki/Resources_Events_Agents, http://reatechnology.com/what-is-rea.html, https://www.msu.edu/~mccarth4/, версия вторая: http://www.managementinformatics.ugent.be/cgi-bin/php-cgiwrap/a64526/REAv2-WIKI/index.php?title=Main_Page, связка с DSL (профиль UML) -- http://www.dsmforum.org/events/DSM10/Papers/Gailly.pdf

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

В этих паттернах четко прослеживается duality (которая по сути -- поставка против платежа. Далее идем к "квантовой теории" прав, и добрым словом поминаем 4D-онтологию). Ну, и постоянно вспоминается DEMO с ее трансакциями и дискурсом.

Основные концепты:
-- economic resource: A thing that is scarce and has utility for economic agents and is something users of business applications want to plan, monitor and control.
-- economic agent: An individual or organization capable of having control over economic resources, and transferring or receiving the control to or from other individuals or organizations.
-- economic event: A change in the value of an economic resource that is under the control of the enterprise. Each economic event is either an increment economic event or a decrement economic event.
-- commitment: A promise or obligation of economic agents to perform an economic event in the future. Each commitment is either an increment commitment or a decrement commitment.

Основные аксиомы:
-- stockflow axiom: At least one increment economic event and one decrement economic event exist for each economic resource; conversely increment and decrement economic events must affect
identifiable economic resources.
-- duality axiom: All decrement economic events must be eventually paired in duality relationships with increment economic events and vice-versa.
-- participation axiom: Each economic event must be related by a provide relationship to an economic agent and by a receive relationship to an economic agent.
-- reciprocal axiom: Each increment commitment must be related by a reciprocity relationship to at least one decrement commitment and vice versa.
-- fulfillment axiom: Each commitment must be fulfilled by at least one economic event; increment commitments must be fulfilled by increment economic events and decrement commitments must be fulfilled by decrement economic events.



Конечно, различных экономических онтологий множество. Но не все они дошли до уровня ISO и рутинно преподаются бухгалтерам. Нужно будет приглядеться.

На закуску: слайды и papers с семинара Ontological Specification of Interoperability Semantics for Financial Information and Business Reporting Systems (2008) -- http://nsfaccountingontology.wik.is/Workshop

И гораздо больше свеженьких статей (июнь 2007г) с конференции "25 лет REA" -- http://www.aisvillage.com/rea25/program.html и там еще http://www.aisvillage.com/rea25/Track2Papers.htm. В принципе, после этой конференции тамошние люди начали понимать, что Resource это в экономике не столько он сам (деньги или вещи), сколько Rights -- http://www.managementinformatics.ugent.be/cgi-bin/php-cgiwrap/a64526/REAv2-WIKI/index.php?title=CommitmentsClaimsAndResources. И это исходя из чисто онтологических проверок! Истинная априорность подхода ;)

kuznetsov в 2007г. после своего доклада на Лебедевских чтениях по аксиоматике в праксеологии и экономической теории (см. http://g-l-memorial.ice.ru/135691) думал вернуться к этому вопросу. Еще пара лет, и можно будет ему об этом напомнить. Надеюсь, у нас к этому времени будет уже какой-то инструментарий, чтобы не в пауэрпойнте аксиомы выписывать...