как лингвисты проиграли последнюю битву за NLP

 Конец ABBYY — это конец большой мечты. Мечты, которая родилась много десятилетий назад, задолго до самой компании. Мечты о том, что лингвистическая теория — то есть все те способы моделировать язык, которые придумали ученые-лингвисты, —  поможет сделать наиболее точные инструменты автоматической обработки языка. Ведь это логично: чтобы создать атомную бомбу, надо понять устройство атома и атомного ядра. А чтобы создать машинный переводчик или систему автоматического извлечения информации из текста — надо понять устройство языка. Так?

На самом деле нет. По крайней мере всё, что мы знаем на сегодняшний день, указывает на обратное. Чем более успешными становились прикладные системы работы с естественным языком (информационный поиск в интернете, машинный перевод, распознавание речи, чатботы-ассистенты), тем меньше в них оставалось какой бы то ни было лингвистики. Этот тренд был замечен еще в конце 80-х — начале 90-х, когда в Америке стала популярной фраза, приписываемая Фредерику Елинеку, руководителю разработок по распознаванию речи в IBM:

«Каждый раз, когда мы увольняем лингвиста, качество работы системы повышается»
Фредерик Елинек

История компании ABBYY — это история трех десятилетий попыток опровергнуть этот обидный для лингвистов афоризм. Попыток, которые стоили десятки миллионов долларов, но так и закончились ничем. 

«Мир есть совокупность фактов, а не вещей»: Витгенштейн и операционно-ориентированное программирование

За каждым методом бизнес-логики стоит факт мира, который этот метод (чаще не в одиночку) моделирует. Факты программирования – это операции: дальше будем называть их так. Делая метод членом класса, ООП требует от нас привязать операцию к объекту, что невозможно, потому что операция – это взаимодействие объектов (двух и более), кроме случая унарной операции, чистой рефлексии. Метод ВыдатьЗарплату (PaySalary) может быть отнесен к классам Сотрудник (Employee), Касса (Cash), БанковскийСчет (Account) – все они равнозначны в праве владения им. Дилемма о расположении методов сопутствует всему процессу разработки: неловкое ее разрешение может оказаться критичным и даже фатальным.

В книгах по программированию честные авторы стыдливо признают, что «объекты – это как бы не совсем объекты», а ООП – всего лишь способ организации кода, а не механизм моделирования. Но все дело том, что «мир есть совокупность фактов, а не вещей» – отсюда принципиальная неспособность построить адекватную модель, применяя ООП в том виде, как этого требуют писатели учебников. Важно понять: в коде возможно моделировать мир, но атомами модели должны стать факты, а не объекты.

Оказавшись два года назад в мире разработки ПО, я с ужасом осознал, что тут до сих пор царит Аристотель: ООП – прямое порождение его философии. Этот одиозный мыслитель придумал флогистон для химиков, движущую силу для физиков – да что там говорить! — приложился к каждой из крупных дисциплин. История европейского прогресса – это история преодоления Аристотеля. Науке он принес больше зла, чем вся Святая инквизиция. Две тысячи лет потребовалось нашим ученым, чтобы затереть следы его «Физики». ООП – последнее пристанище его мрачной тени. Встречаясь с ним здесь — в ядре самых передовых технологий — хочется взять античный стилус стимулус (так в Риме называли палку погонщика скота) и загнать злобного грека обратно в его каменные склеп, как это давно уже сделали все остальные.

Сложность кода и яма со смолой

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

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

Что хотел сказать автор своим произведением, достиг ли он своих художественных целей - вот правильные вопросы к программисту!

vit_r  Программирование всегда было гуманитарной наукой, просто профессора не хотят быть приписаны к ним и паразитируют на факультетах наук естественных, измышляя левые теории.

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

О выразительности говорят давно. (По крайней мере, с момента возникновения Перла :-) )

К гуманитариям на поклон идти бесполезно. (Поверьте человеку, который это двадцать лет пытается делать.) Они знают только свою полянку, но совершенно не могут перенести методы на другие области. Внутренние начинания вроде literate programming дохнут в зародыше, потому что программисты не утруждают себя лишними нажатиями на клавиши.

По-моему, ошибка состоит в наивном "моделировании" предметной области с помощью об'ектов. Типа, раз я имею дело с байтами, битами, портами, аппаратными интерфейсами и проч., то надо создать соответствующие классы.

А на самом деле ООП это инструмент (один из) чтобы "правильно" организовать/структурировать программу (computation). Собственно, ругательски ругаемый нынче ГоФ это и показал: У нас же в предметной области нет "фабрик", "синглетонов" и "команд". А классы такие есть. И встречаются в самых разных предметных областях.
 ivan-gandhi.livejournal.com/2844985.html

именно.

Ошибка преподавания и использования ООП в моделировании предметной области.

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

на примере обычного языка:

ООП сейчас часто применяется как:
видим в предметной области:
"... в наивном ..."
аха, вот он класс Naively
встречаем
"... в наивных ..."
аха, наследуемся
встречаем
"... это наивно ..."
аха... соображаем что наверное это базовым классом должно быть - Naively. переделываем.

встречаем
"... глупо ..."
новый класс

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

а надо бы
1. либо проектировать от правил - части речи, падежи
2. либо, "статистически" от букв, слов, порядка слов, устойчивых связок слов

то есть, предоставить более абстрактные, мелкие классы - для выражения утверждений предметной области.
именно в этом суть совета строить не наследованием - B is A, а композицией: В has A

для примера - холивар Rich vs Anemic

3ий подход - DSL, к ООП как таковому не имеющий отношения, а просто по той же идее - дайте с чего собирать утверждения предметной области.

Хард энд софт - мозг и его навыки

эксперимент Р. Гельда (Held R) и А. Хайна (Hein A) с котятами.
Котята выращивались с рождения в полной темноте, и выпускались на свет только в условиях эксперимента. Котятам из первой группы дозволялось передвигаться самостоятельно. Однако, этих котят запрягали в особую тележку, на которой перевозились котята из второй группы, которым не позволялось двигаться: они были зафиксированы в тележке неподвижно. Таким образом, каждый подвижный котенок и его неподвижный «наездник» видели в процессе эксперимента практически одно и то же. Через несколько недель и тех, и других котят выпустили на свет. Первые, ходячие котята вели себя как нормальные зрячие. Вторые же, которых катали неподвижными, были по всем признакам слепы: они врезались в предметы и падали с краев. Реальность котят из второй группы не включала ничего видимого глазами, хотя и глаза, и мозг были у них в полной исправности!
Варела. Этическое умение.

О понимании компьютерами текста

Одна девушка-переводчица, задумчиво глядя в потолок, спросила меня: «А смогут когда-нибудь компьютеры понимать текст так же, как человек?» Тогда я не смог ответить на этот вопрос, но сейчас, обладая некоторыми знаниями в области семиотики текста, я уверен, что так же как человек компьютеры не смогут понимать текст никогда.
(Под компьютером я подразумеваю не абстрактный искусственный интеллект, а именно вычислительное устройство, выполняющее некий вычислительный процесс. Это важно.)
...
Почему же нельзя просто представить все знания интерпретатора-человека в виде семантической сети или множества предикат? Теоретически можно, но объем этой базы знаний будет колоссальным. Каждое слово в каждой фразе порождает определение, которое тоже является фразой из слов, каждое из которых так же порождает определение. И так, пока определения не замкнутся сами на себя. И это, не учитывая сочетаний существительное-глагол, глагол-наречие, идеом и т.д, каждое из которых может иметь свое уникальное определение. Таким образом, объем базы знаний растет экспоненциально относительно словарного запаса интерпретатора. При таких объемах, даже перевод компьютеров на элементную базу масштаба элементарных частиц (если это вообще возможно) не даст достаточных объемов памяти и производительности. В это, собственно, и упирается анализ текстов на сегодняшний день.

 Определенно, человеческий мозг не использует для представления знаний ни один из известных способов. Более того, существует не мало оснований полагать, что мозг работает принципиально не алгоритмически, и значит не может быть смоделирован вычислительным процессом. Выдающийся английский математик Роджер Пенроуз считает даже, что в работе мозга не обходится без квантовых эффектов. В любом случае, как работает мозг, до конца ни кто не знает, и в этой области еще возможно множество открытий. Что же касается компьютеров в современном смысле этого слова, то можно с уверенностью утверждать, что понимать текст они не будут никогда.
S: Самое забавное что большинство комментирующих не поняли аргументации, и вообще о чем речь :)

ИТ-рынок и индекс промышленного производства вместе растут и вместе падают. Но со сдвигом по времени

Несмотря на все разговоры о “драйверности”, “определяющей роли” и т. д., в целом ИТ-рынок является “обслуживающим” рынком и темпы его роста в общем-то определяются темпами экономического роста соответствующего региона.

Кроме того, состояние ИТ-рынка хорошо коррелируется с Индексом потребительской уверенности (см. www.pcweek.ru/business/blog/business/1401.php).

Программирование ближе к лингвистике

Встретил свежий пример, а встречается такое довольно часто что программисты не дружат даже с арифметикой:

Ccoder:
Проблема:
Хочу изобразить очень большую базу данных в JTable размер строк которой > MAX_INTEGER

А что Вы думаете?

думали разное, но в голову не приходило просто посчитать :)

Skipy:
 Я думаю, что для начала надо посчитать объем памяти, которая понадобится, чтобы просто удержать данные в модели. MAX_INTEGER - это 2Гб. Пусть строка таблицы состоит из одного элемента - строки длиной 5 символов. Тогда мы имеем на строку таблицы по минимуму 10 байт на данные (массив символов) + 8 байт на объект (если я правильно помню) + 12 байт на организацию строки (длина, смещение, ссылка на массив символов) + 4 байта на ссылку на строку в модели. Итого - 34 байта. Это абсолютный минимум. Умножим на 2Гб строк - и получим 68Гб - ШЕСТЬДЕСЯТ ВОСЕМЬ ГИГАБАЙТ!!! - памяти.

Ccoder, Вы все еще хотите показывать всю таблицу, или же перейдете к обдумыванию постраничного просмотра?

Будущее ИТ

Полутора-часовое выступление.
Весьма вероятно что будущие операционные системы будут устроены вот так: 

Фантом-ОС (Дмитрий Завалишин на ADD-2010) from Stas Fomin on Vimeo.


А вот такого будущего, уверен не будет.
Это как фантастика 1930-1950ых, где космонавты, пользуются логарфимическими линейками. 
Приключения Алисы в Сколково - 2023


Скорее будет как у Вернора Винджа в "Конце радуг" описано.

Почему программирование - сложно?

Потому что требования «вертикальны», а решение «горизонтально». Сейчас я объясню.

Кто сможет разработать национальную ОС?

... во время выступления директора ГНУ/ЛинуксЦентра Павла Фролова ...
Из зала ему был задан вопрос, а кто же, собственно, станет заниматься разработкой национальной ОС. И г-н Фролов без долгих раздумий откровенно ответил, что ему это совершенно не понятно. В том смысле, что профессиональных разработчиков у нас раз-два и обчелся. А те 50 навскидку человек, кто обладает нужной компетенцией, ни в какой коллектив не объединены. И единственный, по мнению Фролова, продуктивный способ оперативно создать российскую ОС — собрать эти полсотни программистов и по старинке запереть в шаражке.

Нам поступил на реализацию проект

— Нам поступил на реализацию проект... нужно нарисовать семь красных линий. Все они должны быть строго перпендикулярны, и кроме того, некоторые нужно нарисовать зеленым цветом, а еще некоторые — прозрачным. Как вы считаете, это реально?
(P.S. alex_aka_jj: У меня есть хорошая знакомая, которая однажды нарисовала корпоративный календарь. Ей сделали выговор за то, что она дура и не знает, что каждый месяц начинается с понедельника, а у нее в календаре - как попало.
На следующий день отнесла тот же календарь снова - взяли, похвалили.
Не вру, честное слово.) 

Печатная машинка...

50 цитат о программировании всех времён

выборочно

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

- Rick Cook 

Ходить по воде и разрабатывать программы, следуя спецификации, очень просто… если они заморожены.
- Edward V Berard 

Объектно-ориентированная версия "спагетти кода" - это, конечно, "лазанья код" (очень много слоев).
- Roberto Waltman 

В теории, теория и практика неразделимы. На практике это не так.
- Yoggi Berra  

Изучение программирования имеет такое же отношение к проектированию интерактивных систем, как обучение слепой печати к написанию стихов.
- Ted Nelson 

Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
- Brian W. Kernighan.  

Большинство программ на сегодняшний день подобны египетским пирамидам из миллиона кирпичиков друг на друге и без конструктивной целостности - они просто построены грубой силой и тысячами рабов.
- Alan Kay 

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

Итерация свойственна человеку, рекурсия божественна.
- L. Peter Deutsch 

Я всегда не любил Symbian.

Хорошая иллюстрация моим словам, пример из не такой уж и далекой истории: Palm OS и Windows CE. Когда Microsoft представила миру свою мобильную платформу, все схватились за голову -- засунуть в железки того времени взрослую 32-х разрядную ОС, с защитой памяти, честной многозадачностью и прочими атрибутами десктопной Windows -- в то время это казалось самоубийством. Однако время расставило все на свои места, прошло не так много времени, и Palm OS стала казаться игрушкой для детей из приюта для имбецилов, а решения на основе WinCE полностью завоевали рынок КПК.
...

... знаете какую очень серьезную ошибку, в свое время, допустила Nokia? Она попыталась ответить на сенсорный бум, вызванный сами знаете каким телефоном, решением, основанным на многострадальной Symbian, которая и без этих костылей дышала на ладан.
Как говорил один малоизвестный еврей -- не стоит лить молодое вино по старым бурдуюкам. И латать прогнившую рубаху бесполезно.
Ну на хрена надо было связываться с Symbian? Ради чего? Ради трех с половиной убогих программ? Которые, кстати, в S60 5th все равно так толком и не заработали, потому что эту самую S60 безрукие люди делали. Да и привлекательная, на первый взгляд, идея простой “перекомпиляции” на практике не так уж интересная -- по хорошему UI все равно весь надо переделывать.
А ведь если бы в Nokia хоть кто-нибудь помнил ... историю той же Palm OS, то на этой исторической развилке зеленый свет зажегся бы для Maemo. При этом учтите, что с момента анонса первого iPhone до появления 5800 прошло два (!) года, а с учетом того, что стартовать с Linux платформы было бы значительно проще, чем с обремененного старыми проблемами Symbian... В общем, кто знает (пардон за сослагательное наклонение), в каком положении была бы компания сегодня, не соверши она такую стратегическую ошибку.

Психолог с подпольным стажем

Андрей Педоренко (ИТ директор)


Когда человек понимает, что он достиг бетонной стены, он переходит в другое место и пытается сдвинуть стену на новом уровне. Всегда есть кредит доверия к новому человеку, и некоторые вещи меняются быстрей, чем если ты долго работаешь на одном месте, где все тебя знают. Это не всегда носит объективный характер, это не всегда соответствует внутренним возможностям человека, но сам переход дает возможность сдвинуть планку. «Ведь мы же его взяли, — считает руководство, — и раз уж он говорит, что надо делать так‑то, дадим ему “карт-бланш”». Кредит доверия на одном месте очень трудно получить. ...

В устоявшейся среде пробить «стену» гораздо сложней.
...

Отлично работает пиар-метод «ОБС (одна бабка сказала)». У меня раз в год гигантский стресс — защита бюджета на учетном комитете. Защищаю отдельно каждую из 350 статей расходов. При этом обосновать стоимость сервера или системы хранения очень просто — с ними никто не спорит, потому что не знают про них ничего. Но вот про мелкие гаджеты все всё знают! Более того, у каждого топа есть свой знакомый, «хорошо разбирающийся в ИТ», который сказал, «что все можно сделать дешевле и проще». «Давайте все сейчас перейдем на Google Office, и все будет чудесно!…» И тут у меня начинают опускаться руки, поскольку я понимаю, что где‑то недоработал, раз вообще возник такой вопрос. Видимо, нужно было заранее что‑то людям объяснить. И тут опять встает вопрос доверия. А, к сожалению, СИО можно доверять только как врачу — либо полностью, либо никак. Проверить его просто так, на ходу, нельзя. Нужно тогда создавать группу аудита, внутреннего или внешнего, консалтинга, который по каждому ответу даст экспертное мнение.

У нас был опыт с привлечением внешнего аудита — Gartner. Мы с операционным директором написали ИТ‑стратегию на пять лет, вынесли ее на правление, а нас просто не стали слушать. Мы представили информационные системы, которые нам в течение пяти лет нужно внедрить, от хранилища данных до фронт-офиса. Но тогда один из недавно пришедших топов заявил, что все это ерунда, нужно просто обратиться в магазин, к ИТ-вендорам и купить у них нужное самого лучшего качества. «Все уже разработано, и внедрять тут ничего не нужно. Вам нужен миллион долларов? Возьмите и поставьте все, что надо, но только это лучше сделать быстро, сразу». А все пояснения, что так не бывает, что нет продуктов, которые точно, как мы хотим, лягут на нашу компанию и процессы, — были встречены в штыки. И мне было заявлено, что и мой опыт ничего не стоит, и вообще я занимаюсь не тем, чем надо. Это надолго нас поссорило. Но прошло время, мне стало ясно, что он хороший профессионал в своей области, и постепенно мне удалось его убедить в том, что он был неправ в своих оценках. И когда в кризисный год решался вопрос, что финансировать в первую очередь, он настаивал на инвестициях в ИТ. Мы больше не противники.

Так, что решили на счет спора - "sap vs oebs" - за кем будущее?

Garya:
Выскажу немного крамольное предположение, что ни за тем, ни за этим. Пока два огромных динозавра грызуться за добычу, они не замечают, как эпоха динозавров очень быстро сходит на нет. И SAP, и OEBS - ERP-системы, ориентированные на автоматизацию бизнеса, базирующегося на функциональном менеджменте. До недавнего времени такой тип бизнеса еще имел какой-то резерв развития. Однако, этот резерв практически исчерпан. Следование принципам функционального менеджмента в ближайшем десятилетии станет гарантом его схода со сцены. Поэтому в самое ближайшее время наступит эра систем автоматизации нового типа - базирующихся на процессном менеджменте. Уже не просто обозначился, но и достиг заметного прогресса сектор ПО, позволяющих решать задачи менеджмента с совершенно новых позиций - это BPM-системы. И то, что BPM-системы постепенно станут вытеснять ERP-системы - это не только мое мнение, но и мнение Gartner:

цитата
К 2014 году сети бизнес-процессов (business process networks, BPNs) будут лежать в основе 35% новых интегрированных мультикорпоративных проектов.
...
К 2014 году 40% руководителей бизнеса и служащих крупнейших компаний будут использовать модели бизнес-процессов для обеспечения своей ежедневной работы по сравнению с 6% в 2009 году.

Обсуждение: Неудержимый червь Stuxnet, или о плюшевом вредителе

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

«Они (авторы троянца) смогли создать проблемы. Все проблемы носят ограниченный характер и по большей части связаны с программным обеспечением, установленным на электронных узлах систем», — сказал Ахмадинежад.
Президент Ирана признал, что червь Stuxnet нанес урон ядерной программе страны

Так, друзья, хохочущие и неверящие. Давайте знакомиться: инженер группы поддержки программных средств цехов основного производства по производству ТТ (Топливных Таблеток), ТВЭЛ (Тепло-Выделяющих ЭЛементов) и ТВС (Топливно-Выделяющих Сборок) Новосибирского Завода ХимКонцентратов, входящего в структуру ОАО ТВЭЛ и в Госкорпорацию "РосАтом". По простому - эти цеха производят весь техпроцесс, начиная от получения порошка диоксида урана до упаковки и отправки потребителям готовой продукции. А я в них обслуживаю технику и АСУТП.

Итак, друзья, вот вам факты:
I. Разработка:

Agile разрушил мою жизнь

Тренеры, которые не могут выполнить работу. У меня есть хорошие друзья, преподающие Agile, которые годами не программировали и не руководили командой, поэтому у них я прошу прощения. Если вы собираетесь обучать чему-либо, вы должны уметь это делать. На очень высоком уровне компетенции. Agile-тренер должен уметь программировать, выполнять анализ, руководить проектом, тестировать – все необходимое для ведения проекта. Если вы не можете, то как с вами можно разговаривать о специфических ситуациях? Если ваш agile-тренер получил степень бакалавра на прошлой неделе или не написал ни строчки кода или является профессиональным тренером или – давайте будем по настоящему честными – приносит меньше пользы чем члены команды, он бесполезен. В этом виден здравый смысл, но лучше повторить: вы не можете обучать тому, что не делали. И «делание» означает «многократно», а не один пилотный проект. Одна компания пригласила меня подготовить нескольких agile-тренеров. Эти люди ничего не знали про Agile две недели назад, когда я побывал у них первый раз. Блин, если бы я смог, то был бы завален деньгами, но так не бывает. Ходит ли кто-нибудь в школу для того чтобы стать тренером по бейсболу? Или сначала они учатся играть в бейсбол, а потом лишь часть из них осознает, что у них есть талант к преподаванию? Девять женщин не смогут за месяц родить одного ребенка, и неважно, как сильно вы этого хотите.
...
Я работал с дамой, которая в своей статье спрашивала: «Почему мы недовольны неуспешными Scrum-командами, если на самом деле они не следуют принципам Scrum?» Проповедовать список действий, которые надо выполнить идеально, и считать неудачу следствием их невыполнения – это, по существу, религиозная установка. Никогда не удастся сделать достаточно. Команда провалилась? Не было достаточного Agile. Вздор, вот что это. Много прекрасных agile-команд терпят неудачу. И много команд успешны без Agile.

Куда идет NoSQL с MongoDB

(Почему NoSQL)
Проблема в том, что сильная сторона реляционной модели — сама реляционная модель — это и ее самая большая слабость. Большинство разработчиков (что бы они ни использовали — .NET, Java или нечто совершенно иное) после нескольких лет работы может в красках описать, что не все так ладно с «квадратной» моделью таблиц/строк/столбцов. Попытка смоделировать иерархические данные может довести до бешенства даже самых искушенных разработчиков, ... И если к этому добавить базовую «данность», которая заключается в том, что реляционные базы данных предполагают отсутствие гибкости в структуре данных (вспомните схему базы данных), то попытка поддерживать «дополнения» в данные по месту приводит к весьма громоздким и запутанным конструкциям. (Быстро голосуем поднятием рук: кто из вас работал с базами данных, в которых был столбец Notes, или еще лучше, столбцы Note1, Note2, Note3…?)