Pull to refresh

Comments 32

UFO just landed and posted this here
Присоединяюсь к благодарности за хорошую статью.
P.S: Сам сталкивался с подобным при репликации Excel'евской функции TEXT со всеми возможными форматированиями :)
Жесть какая.

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

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

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

После прочтения обеих частей так и хочется сказать: «Как я вас понимаю!».
Казалось бы, занимаемся совершенно разными проблемами (я занимаюсь автоматизацией машиностроения), а все проблемы одинаковые (хотя они у всех сложных систем одинаковые наверное), да и про теоретически/математическое решение проблем верно.
Хороший годный текст, но слишком уж много смехуёчков. Ну то есть понятно, для чего они нужны, только слишком уж. Как будто автор писал текст по американской методичке для священников.
Не, чуваки, а почему минусуете? Я же тоже умный!
1. Минусуют не столько Вас, сколько Ваш комментарий (надеюсь). Комментарии обычно минусуют, если считают его недостаточно умным/интересным.
2. Вас могут начать минусовать если Вы будете писать много таких комментариев. А также сказать что-то обидное и/или указывать пользователям как и за что голосовать.
Ну так тексты без смехуёчков всегда можно почитать в технической и научной литературе. Открываете любую серьезную книжку и будет там много много сотен страниц формул, математического описания итд итп, или открываете какую-нибудь статью в журнале и там всего 20 страниц, но написано частенько так, что на ее чтение надо несколько дней потратить. А тут и проблема затронута серьезная, и читается легко, что еще надо для счастья?
Вообще, писать скушный тект, который никто никогда не прочтёт и даже компилятор сдохнет от зевоты — пустая трата времени. Довольно известен парень, сформулировавший эту мысль ранее.
> Многие из самых изощренных и бесчеловечных серийных маньяков с детства отличались патологической склонностью к жестоким издевательствам над животными. Этот факт не имеет отношения к теме статьи — я просто хотел убедиться, что вы не заснули.
Прям как наш лектор под конец темы, видя, что многие носом клюют. И, да, действует.
Порадовало «картинки не будет», и «один раз не копипаст» — с юмором у Вас все в порядке. :)

Планируете нас дальше радовать?
Как долго? Как часто?
Спасибо за комплимент. Если будет что рассказать по существу — расскажу.
Спасибо за статью!

Интересно было бы посмотреть на пример решения какой-нибудь «грязной задачи» на практике. Я имею в виду, сам подход к решению, последовательность Ваших действий при столкновении с тем или иным «грязным препятствием», пример применения всех описанных техник в статье.

Было бы интересно почитать. :)
Такое я бы тоже хотел почитать. :) Применительно к ABBYY я не очень уверен в том, насколько я имею право раскрывать подробности.
Очень интересная статья, я тоже склоняюсь к мнению что в борьбе с грязью и копипастом программисты забывают для чего пишут программы.

Но больше всего я тащусь по стилю изложения ;) Продолжайте, пожалуйста!
Ого, прямо «тащусь»? Вот вы тоже считаете это чем-то необычным? Да, контекст интересный и по-своему уникальный, но вот именно стиль изложения, неужели это ок? Вы не видите здесь заискивания перед публикой? Не вопиющего, да, но с лёгким налётом пошлости, а?
Когда человек творит для других и пишет так, чтобы другим легко и приятно читалось, с чувством юмора — почему это плохо? Я примерно представляю сколько автор провёл времени над перечитыванием статьи, вычищением тех мест, которые плохо читаются, разнообразил свою речь метафорами.

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

Я бы не называл это заискиванием перед публикой — иначе Толстого и Булгакова, которые «вылизывали» свои произведения десятки лет, тоже можно назвать лицемерами. Я двумя руками за то, чтобы техническая литература была написана простым языком и с юмором.
Пожалуй, самый показательный случай грязной системы в моей практике — заполнялка веб форм (заполняет за вас имя, адрес и другую персональную информацию). Мне довелось принять участие в разработке, правда сам механизм заполнения я не трогал.
Процесс заполнения состоит из двух этапов.
1. Нужно найти поля (выпадающие списки, радиобаттоны и т.п.) и описание, что в этом поле находится.
2. Заполнить поля.

Самый сложный этап конечно первый. Нужно правильно сопоставить окружающий текст к нужному полю. С учетом того, что текст может быть справа, слева, снизу или сверху от поля, решение получается нетривиальное. Текст может вообще отсутствовать, как например у второй строки адреса. По сложности, не сравнить с тем что встроено в Firefox, например.
Так вот здесь куча эвристик, например таких:
1) расстояние между текстовым описанием поля и полем справа не может превышать половину ширины поля.
2) расположение описания у первых N полей задает расположения для остальных полей, и если способ «немного не подходит для поля», то стоит это проигнорировать. А если сильно не подходит, то это начало другого блока полей.
Самое страшное, что вся эта логика заключена в одной огромной функции, а в ней два огромных цикла. И никто рефакторить ее не собирается, видимо, потому что бояться все сломать.
Вот такое сочетание грязи в эвристике и грязи в коде.
Огромное спасибо за такую чистую и светлую статью про темную сторону программирования :-)!

В своей практике я мало сталкивался с написанием эвристик (хотя и такое случалось), но довольно часто сталкивался с такой «эвристической продукцией» в виде компонентов, решающих некоторые задачи. Мой опыт показывает, что такие компоненты всегда представляют собой «человеко-машинный» комплекс. Почему-то «грязная» составляющая задач почти всегда приводила к очень грязному коду, в котором никто кроме автора не мог разобраться. При этом нельзя сказать, что на автора давили какие-то сроки, напротив, авторы подобных компонентов, как люди творческие, часто имели довольно свободный график в плане выпуска, они отдавали свои решения «в народ» когда решали что все готово.

Поэтому особенно приятно читать у автора алгоритмов, решающих «грязные» задачи, о важности чистоты кода, эти задачи решающего.
Я, конечно все понимаю. Но причем тут ИИ? Вы декларируете — что эвристическое программирование — есть грязное дело. И как бы сложность задачи извиняет зоопарк решений, причем решений далеких от идеальности как по результату, так и по качеству кода.

Тут можно согласится в том, что нет ни какой необходимости правильно оформлять код для алгоритма, которого собственно и нет. Если алгоритм это набор предположений, частных попыток решить проблему — это не алгоритм. Конечно правильно, что общие решение невозможно без частного. Но так или иначе должен быть свет в туннели. Декларировать наличие грязного программирования — плохо. Скорее надо вводить понятие «проведение частных экспериментов», или скажем так экспериментальное кодирование.

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

Что касается качества кода, то я не писал, что хорошее оформление кода для эвристических алгоритмов не нужно; более того, я утверждал обратное.

По поводу «экспериментального кодирования» — в статье речь не об экспериментах, а о создании промышленного образца, решающего задачу. Соответственно, код предполагается довольно долгоживущим.
Тогда мне сложно вас понять. Как я понимаю термин «грязное программирование» ваш. Было бы на порядок проще понять, что вы имеете введу, если бы Вы дали бы его определение. Грязное программирование — это… (или когда… )?
Термин «грязное» в рамках этой статьи обозначает эвристическое. Грязное не в том смысле, что код неаккуратно пишут, или что классы не выделяют, или что goto используют, и вообще не как антоним чистому коду. Имелось в виду, что эвристики сами по себе, безотносительно воли разработчика, создают определенные сложности с поддержкой и развитием программы.
Или Вы считаете, что программирование с применением эвристик по определению «грязное» и другого быть не может? Тогда я с вами не согласен.
> По поводу «экспериментального кодирования» — в статье речь не об экспериментах, а о создании промышленного образца, решающего задачу. Соответственно, код предполагается довольно долгоживущим.

Что же касается этого. То в прошлой статье, вы декларировали, что не математика, не т.н. мягкие вычисления не позволяют решить вашу задачу. А значит вы на это махнули рукой, и занялись «эвристическим программированием». В применении эвристик нет ничего плохого — собственно компьютерные шахматы это хорошо нам демонстрирую. Но вот какая штука — в шахматах эвристики используются как дополнение к теории игр. Вы же как я понял используете ТОЛЬКО эвристики, в математической теории у вас даже близко нет.

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

А следовательно, у вас методы программирования ровно такие же как в «экспериментальном кодировании», а так как вы вынужденно пишите это как промышленный продукт — то тут и получается ваши субъективные неувязки с появлением «грязного программирования».
> Вы же как я понял используете ТОЛЬКО эвристики

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

К тому же обилие эвристик не означает, что программа представляет собой аморфный кусок кода. Система должна иметь четкую архитектуру; разработка должна вестись в рамках какой-то общей стратегии; перебор на верхнем уровне должен быть грамотно организован и так далее. Просто статья посвящена именно эвристикам.
Тогда другое дело. Но из статьи это не следует.
Sign up to leave a comment.