Category: it

Category was added automatically. Read all entries about "it".

Предложение по усовершенствованию JavaScript

Выдвигаю предложения по усовершенствованию синтаксиса языка JavaScript.

Для примера разберём такую простую конструкцию, как функция, генерирующая замыкания.

function foo(filter, pattern) {
    var f = function(list) { return filter(pattern, list); };
    return f;
};

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

Распознавание речи? Пока без прорывов

Подсыплю ложку первоклассного дёгтя.

Слышали про Сколковский/Казанско-IT-парковский проект распознавания речи при помощи, в том числе, информации о движении губ с видеокамеры?

http://realspeaker.net/ru/

Они получили 9 миллионов финансирования, etc.

Что представляет собой проект? Это программа, которая комбинирует готовые открытые библиотеки распознавания лиц из проекта OpenCV/Emgu.CV (Open Computer Vision) и готового же онлайнового гугл-сервиса по распознаванию аудио (Google Speech Recognition API — то же самое, что происходит при распознавании речи в каждом Андроиде, ровно то, что уже доступно каждому JavaScript-программисту в браузере Chrome, и ровно то, на основе чего мы с sidentdv за одну ночь на ульяновском хакатоне написали проект AudioSMS).

Как комбинирует? Берёт аудио с микрофона и по сети посылает в гугл API, пока губы движутся, и не посылает, пока губы не движутся. Эта зависимость от движения губ называется «детекцией пауз». Сервер гугла в ответ присылает в текстовом виде распознанный текст.

Почему это не прорыв? Потому что если не обладать возможностью действительно встроиться в алгоритмы распознавания аудио, нельзя сделать глубокий фидбэк видео от губ. Например, подмешать видеопоток в bayesian language model. То есть, нельзя сделать так, чтобы губы действительно влияли на качество распознавания аудио. Максимум что можно сделать — вот это самое распознавание пауз, при котором шум с микрофона не посылается в гугл.

Может быть это какое-то демо, а у них в лаборатории готовится реальный прорыв? Да, они пишут, что это прототип. Хотя и продают его Pro версию за 1000 рублей. И хочется верить, что у команды есть более тяжёлая артиллерия. Но не думаю, что это так.

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

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

Вектор зачистки интернета

Помните новость про фильтрацию интернета четырёхлетней давности?

Поставить шлюз между Рунетом и остальной Сетью предлагает президент отечественной ассоциации разработчиков ПО Валентин Макаров. По его мнению, шлюз, через который будет открываться доступ к зарубежным ресурсам, обойдется в несколько сотен миллионов долларов, а его возведение займет около 10 лет. Необходимость защитить Рунет от внешних угроз ранее также высказывал и министр связи Игорь Щеголев.

Подробнее: http://internet.cnews.ru/news/top/index.shtml?2008/10/24/324624


Я об этом писал здесь: http://lionet.livejournal.com/28584.html

Министр связи уже сменился, но желание контролировать интернет никуда не исчезло. Появилась мерзкая, с двойным дном, «Лига безопасного интернета», которая делает ровно то же самое, но теперь прикрывается, как и положено сейчас в политическом процессе России, детьми и их интересами.

Советник исполнительного директора Лиги безопасного Интернета, которая выступает сторонником этой идеи, Валерий Пономарев рассказал «Газете.Ru» о том, что его организация ведет переговоры по поводу тестового запуска проекта «чистый Интернет» с губернаторами [некоторых] регионов, и скорее всего, эксперимент проведут в одном из них. Суть «чистого Интернета» такова: если пользователь захочет оставить себе доступ ко всем ресурсам Интернета, он должен будет указать это в контракте, который он будет заключать с провайдером, фактически на манер фильтрации контента, предлагаемой крупнейшими поисковиками, например, Google.

Подробнее: http://www.gazeta.ru/business/news/2013/01/31/n_2733657.shtml


Хорошо, что Ульяновская область в этот кружок некоторых регионов не входит, а то были бы сильные репутационные потери. Руслан Фазлыев aznakai:

Вообще я уверен что долговременное сотрудничество с этой "Лигой" способно нанести репутационный демейдж кому угодно. Потому что я лично уверен, что в цели этой организации не входит вообще никакая безопасность Интернета, безопасность детей и т.п. Эти задачи по-другому решаются.
<...>
Все это заворачивается в красивую обертку заботы о детях. Оставьте эту заботу родителям

Казалось бы, пока цензуру не ввели, нечего дёргаться? Но вот как интернет выглядит в России уже сейчас:

Dmitry Tarakanov: Как меня ограничили уже сейчас: 1) давеча искал информацию по конфигу базы данных MySql, гугл выдал какой-то сайт с инженерными выкладками - доступ к сайту заблокирован и картинки провайдера Билайн, мол, сайт внесен в список...закон блаблабла 2) чуть ранее решал вопрос связанный с языком программирования php - заблокировали нужный сайт 3) хотел прочесть статью про язык программирования Haskell - тоже самое, провайдер не дал мне этого сделать. Я, как технический специалист, уже сейчас испытываю трудности в использовании местного Интернета. В первых 2-ух случаях сработал только фильтр провайдера, т.е. в реестре zapret-info.gov.ru их(уже?) не было. А за хаскель обидно. Но я себе настроил VPN в США - и это пока спасает, надеюсь не начнут резать впн-трафик на выходе из страны.

Виктор Бакурин: Сам тоже натыкался на блокировку Yahoo Groups на уровне провайдера (Dars Telecom). Хотя я просто гуглил прошивку на Arduino. Решается пока аналогично через VPN.



В итоге уже сейчас это политически выглядит на уровне Китайского Файерволла, и стремительно приближается к Северокорейскому. Цензура? Свобода слова? Свобода собраний и ассоциаций? Пфф...

Записи ЗАГСа и машинное обучение #ulsk

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

Давайте посмотрим. Пять миллионов записей. Шесть тысяч рублей в месяц зарплата легковооружённого дроида, 6 часов работы в день. Каждая загсовская запись — это, скажем, 30 секунд работы по вбиванию. Может даже минута.

5000000 / (4 * 5 * 6 * 60) / 2 = 347 месяцев работы одного человека, или около двух миллионов рублей денег только на зарплату. Если мы хотим оцифровать пять лямов за год, а не за 30 лет, нам понадобятся 30 человек.

Никакой погоды эти тридцать data-entry человек в масштабах Ульяновского «айти» не сделают.

Зато если потратить эти два лимона на двух аспирантов в годовом проекте оптического распознавания этой всей хрени, это получится три тысячи долларов в месяц на каждого аспиранта. И это в результате будет хайтек-проект, который затем можно будет тиражировать по стране, а то и дальше. Это высокотехнологический, среднерисковый проект, который может масштабироваться далеко за пределы ульяновской области.

Почему машинное распознавание рукописного текста в данном случае не является бредом?

  • Это считывание из фиксированной формы, это упрощает.
  • Имена, отчества, названия населённых пунктов повторяются, и OCR может быть натренирована на них целиком.
  • Данные не являются секретными, поэтому то, что не распозналось, можно засылать в РеКапчу. Ну или сделать какой-нибудь порносайт, и в качестве пароля туда просить распознать задетектированное слово или предложение.

Если области хочется вложиться в IT (на самом деле, CS, Computer Science), то на порядок лучше вложить его в политех, где есть необходимая компетенция по нейронным сетям и машинному обучению, чем тренировать 30 бабушек.

Shadow DOM

Вот какой нынче перспективный метод для:

1. Показа более короткого кода по View Source.
2. Защиты от случайных селекторов jQuery, факапящих отображение и поведение встроенных виджетов (<video>, например).



И если первое было уже доступно в Netscape Navigator (современные браузеры как-то начали вместо View Source показывать View Current DOM Tree), то второе для нас, виджетописателей, более интересно.

http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/

Только не поддерживается нигде, и не будет работать в эксплорере ещё лет десять, но концепция удобна.

P.S. Девушка весёлая на видео, побольше бы таких.

Лютый апгрейд подхода к обучению программированию

Вы наверняка уже знаете, что известнейшая Khan Academy, являющаяся пионером по онлайн-образованию школьников, совсем недавно выпустила интерактивные курсы по программированию. В качестве платформы используется JavaScript и библиотека Processing. Вполне логичный и достойный выбор, всячески поддерживаем и одобряем. JavaScript очень даже неплох в качестве первого языка программирования, да и потом в жизни почти каждого инженера он тем или иным образом пригодится. В нашей компании JavaScript вообще является основой бизнеса, ибо «Продукт есть интерфейс».



Брет Виктор — исследователь и визионарий новых интерфейсов человеко-машинного взаимодействия. Я уже писал о нём в моей заметке «Интерфейсы и инструменты»:
Программистам и дизайнерам интерфейсов посвящается. Настолько мощная презентация от изобретателя новых концепций пользовательского интерфейса в Apple, что одним ретвитом @stevebest не обойдёшься.

Так вот, этот самый Брет Виктор сказал, что этот Хан-Академийский интерфейс для обучения программированию — фуфло и туфта.



А так как Брет человек дела, а не только слова, то он написал не просто аргументированную критику связки JS+Processing, использующуюся в курсах Khan Academy, но и потрудился тщательнейшим образом реконструировать возможный интерфейс правильной системы для обучения. Эта работа Брета показалась мне настолько увлекательной, что в голове постоянно крутятся слова seminal paper в применении к данной работе. Это действительно работа мастера. Всем программистам и дизайнерам интерфейсов читать полностью, без вариантов и отмазок.

Читаем: Learnable Programming


В своей работе Брет постепенно, подход за подходом, прилагает очередную мощную идею из своего списка идей и ценностей проектирования интерфейса, и доходит до захватывающих результатов. При этом, его примеры — это не просто картинки, а живые видео-иллюстрации. Это нужно видеть!



Ближе к концу Брет отвлекается от проектирования надстройки над JavaScript, и делится видением по поводу метафор, стоящих за языками программирования.
Каждый язык программирования наполнен метафорами, но некоторые ложатся на мозг лучше, чем другие. Стандартный императивный подход использует метафору «присвоение переменным» — перемещение битов между маленькими коробочками. В отличие от черепашки Logo, эта метафора не была спроектирована для того, чтобы соответствовать тому, как люди учатся и понимают; она просто эволюционировала как тонкий слой над метафорами, использующимися в архитектуре низлежащей машины, такими как «сохранение в памяти».*

* Алан Кей в «The Early History of Smalltalk»: «Операторы присваивания — даже абстрактные — выражают очень низкоуровневые цели... Люди-программисты не являются машинами Тьюринга, и чем меньше их программные системы требуют техники от Тьюринг-машин, тем лучше.»

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

Из дальнейшего рассмотрения метафор, на которых построены некоторые другие языки программирования, мы видим, что Smalltalk (или тот же Erlang, если читать между строк) предоставляют очень вкусную метафору посылки сообщений между объектами. «Эта очень мощная метафора, потому что ролевые игры и разговоры являются мощными встроенными человеческими свойствами.»

Далее Брет Виктор цитирует одного из авторов языка Haskell:
Когда программист пишет модульную программу для решения задачи, он сначала разбивает задачу на подзадачи, затем решает подзадачи, и в конце концов объединяет решения. Способы, которыми программист может разбить оригинальную проблему, напрямую зависят от способов, которыми он сможет затем склеить решения вместе. Следовательно, для увеличения чьей-то способности модуляризировать задачи в принципе, нужно обеспечить новые типы клея в языках программирования.

Функциональные языки обеспечивают два новых, очень важных типа клея... Это ключевая вещь, обеспечивающая мощность функционального программирования — оно позволяет улучшенную модуляризацию.

Что касается среды Processing (изначально это библиотека для облегчения программирования графики для Java, но теперь доступна и на JavaScript, именно её использует Khan Academy):
Недостатки модульности среды Processing являются серьёзными барьерами для рекомпозиции. Программист не может просто взять у друга модель прыгающего мячика и положить рядом его собственного прыгающего мячика. Переменные должны быть переименованы или инкапсулированы вручную, соответствующие функции "draw" и работа с мышью должны быть переплетены друг с другом, и так далее. Можно легко начать работать с существующей программой Processing и изменять её, но язык не поощряет комбинирование двух программ.

Что ещё хуже, зависимость Processing'а от глобального состояния (там хранится графический контекст, например, матрицы трансформаций — lionet) убивает даже простейшие формы рекомпозиции.

Кстати, приводится непрямой аргумент в защиту Objective-C, который я люблю защищать именно из за этого свойства readability для новичков. В цитате ниже мысленно подставьте Objective-C вместо Smalltalk, синтаксис похожий там.
Smalltalk:canvas drawEllipseCenteredAtX:50 y:50 width:100 height:100.
Processing:ellipse(50,50,100,100);
x86 assembly:push 100; push 100; push 50; push 50; call _ellipse

В Smalltalk аргументы дают контекст. В Processing функция "ellipse" точно такая же таинственная, как и в языке ассемблера. Читатель должен подсмотреть или запомнить каждый аргумент — существенный барьер для чтения.

Для того, чтобы освободить меня от необходимости переводить и цитировать — идите и читайте сами :)

http://worrydream.com/LearnableProgramming/

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

P.S. Мы в Echo (aboutecho.com, echorussia.ru) очень сильно хайрим JavaScript-программистов в Ульяновск и Новосибирск. jobs@aboutecho.com

JSON parsers update

Апдейт к моему посту про JSON парсеры. Я тут связался с автором jsmn, и он починил работу с выходным массивом. Теперь по производительности парсинга jsmn минимум в пару раз обгоняет все остальные протестированные проекты: 482 мегабайта в секунду вместо 249 у наибыстрейшего конкурента. Инициализация парсинга тоже происходит быстрее. Из-за неё парсинг множества мелких JSON-объектов происходит тоже раза в два быстрее: 2.3 секунды на мой тест вместо 5.1.

Comparison and microbenchmark of #JSON parsers

Автор C++ о диспетчеризации по типам и о #Haskell

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3449.pdf

Open and Efficient Type Switch for C++

Yuriy Solodkyy, Gabriel Dos Reis, Bjarne Stroustrup


Автор C++, Страуструп сотоварищи, пишет в соавторстве статью о новой библиотеке для диспетчеризации по типам с помощью внешней интроспекции. Написано на шаблонах C++11 и оформлено в виде библиотеки. Называется Mach7. Выглядит в итоге как-то так:



Ну ничё так.

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

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

struct Expr { virtual int eval () = 0; };
struct Value : Expr { ⋯ int eval (); int value ; };
struct Plus : Expr { ⋯ Expr& e1; Expr& e2; };


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

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

Насколько быстро теперь работает? Говорят, примерно как OCaml или Haskell:
Библиотека реализована как стандартный C++11 код с шаблонным мета-программированием и несколькими макросами. Оно работает примерно также быстро, как эквиваленты на OCaml или Haskell, и даже иногда приближается по быстродействию или даже становится быстрее написанного руками C++ кода, который использует Visitor дизайн-паттерн.

Ну это хорошо, что так быстро, как OCaml или Haskell. Вопрос, зачем при таком раскладе использовать C++, замнём для ясности.

Но дальше вообще прелесть идёт: критика паттерна Visitor!
Библиотека Mach7 и идеи в ней были мотивирована нашим неудовлетворительным опытом работы с различными C++-ными фронт-эндами и фреймворками для анализа программ. Проблема была не с самими фреймворками, но с фактом, что мы должны были использовать шаблон проектирования Visitor для того, чтобы смотреть, обходить и обогощать абстрактные синтаксические деревья целевых языков. Мы нашли Visitor-шаблоны неподходящими для прямого выражения логики приложения, удивительно сложными для обучения студентов, и часто более медленными, чем решения для обхода, написанные вручную. Вместо них, пользователи опирались на динамические приведения типов во многих местах, часто многоуровневые, таким образом предпочитая более короткий, более ясный, и более прямой код, нежели чем Visitor'ы. Соответствующий проигрыш в производительности был обычно незамечаем до более поздних стадий кодирования, когда уже было поздно что-то менять.

Ну можно поздравить C++, теперь можно на нём отдельные вещи писать почти так же коротко, ясно и почти так же быстро, как на OCaml.



Кроме функциональщины, в посте есть отсылка к лиспу, к Duff's device, и вообще, хорошая статья, надо студентам давать. C++ — это очень большой, огромный джип, и эта статья — неплохая иллюстрация.

Comparison and microbenchmark of #JSON parsers

Допустим, в вашем проекте понадобилось найти и использовать быструю библиотеку для парсинга JSON. Смотрим на json.org, там есть целый список на выбор.


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

Сводная табличка


ProjectLicenseAPIUTF-8Neg. testsFollowersBenchmarkFinalist?Note
yajlISCSAXYY815/120249 MB/s, 5.1 sYLarge code base.
jsonslMITSAXNY10/2246 MB/s, 5.6 sYTiny source code base.
JanssonMITDOMYY234/5925 MB/s, 52 sY
csonBSD'DOMYYn/a30 MB/s, 44 sY
json-cBSDDOMYN103/4538 MB/s, 29.7 sY
json-parserBSDDOMNY276/2449 MB/s, 12.4 sYTiny! A single source file.
jsmnMITcustomNY65/416 MB/s, 3.3 s
482 MB/s, 2.3 s
YTiny!
js0npub.customNN67/10n/aN
LibUBSDN18/3n/aN
WJElementLGPLN7/2n/aN
M's JSON parserLGPLNn/an/aN
cJSONBSDNn/an/aN


Collapse )

Cache Performance of Lazy Functional Programs on Current Hardware

Arbob Ahmad and Henry DeYoung


http://www.google.com/search?q=Cache%20Performance%20of%20Lazy%20Functional%20Programs%20on%20Current%20Hardware

Cache Performance of Lazy Functional Programs on Current Hardware


Известно, что рантаймы функциональных языков зачастуют имеют отличные от императивных паттерны доступа к данным в памяти. А современные процессоры оптимизируются под паттерны поведения обычных программ, написанных на более распространённых языках.

Существует несколько исследований, показывающих, где и как функциональные языки неоптимально используют ресурсы процессора. Например, в исследовании 2002 года Nethercote и Mycroft исследовали поведение кэша при выполнении нескольких хаскель-программ, и нашли, что ожидания процессора при отсутствии данных в L2 кэше (cache miss stalls) составляли до 60% задержек при работе программ.

Товарищи из Carnegie Mellon решили ещё раз воспроизвести результаты теста 2002 года. Хардвер за десять лет поменялся довольно сильно, и хотелось определить, так ли пессимистично хаскель работает с кэшем второго уровня.

Использовали валграйндовый Cachegrind и Perf, в частности.

Короче, опредилили, что на тех же данных процессор теперь практически не ждёт на миссах в L2. В 2002 году кэша было 256k, а в 2009 году кэша было уже 4 мега.

К сожалению, они ещё внезапно нашли, что дефольтный размер для нового поколения (nursery) в GC хаскеля составляел 256 kb. То есть, старые тесты 2002 года наверняка упирались именно в то, что дефолтные значения были слишком большими для имеющегося размера кэша. В 2009 году этот же размер оказался более приемлемым.

На мой взгляд, эта находка практически полностью переводит обе статьи, и старую и новую, из подобия науки в разряд тыкания палочкой. Авторы старого исследования не заметили, что упираются в nursery, а авторы нового даже не отметили роль влияния GC-опций GHC на скорость программ. Кроме того, за семь лет изменился и характер нагрузки, а считалось всё на тех же тестах с почти теми же параметрами. Ещё одним соображением являются не абсолютные цифры неоптимальностей в хаскель-программах, а сравнения с эффективностью обычных императивных программ, написанных, скажем, на C или C++. Как поменялась относительная эффективность за эти годы? Нет ответа.
As a result, we conclude that the change in L2 cache size is responsible for most of the performance improvement.
Перевожу: «увеличили кэш, стало быстрее работать». Вау.

И всё же, даже до такого уровня исследования абсолютному большинству российских студентов пилить и пилить.