Классные байки.
Помню, сестра рассказывала, со слов бывшего мужа, который подрабатывал эникеем.
В некой конторе сломался floppy-дисковод 3-дюймовик. Забрали на ремонт, взамен поставили заглушку, помните, старенькие такие, формой повторяли «мордочку» floppy. Утром приходит на работу секретарша (именно ША!) Ближе к обеду звонок, паника в голосе — ваш дисковод сожрал у меня пачку дискет!
Приезжают и выясняют, что секретарша, увидев заглушку, применила творческий подход — пилочкой для ногтей (sic!) пропилила (!!) в заглушке отверстие для дискеты. Вставила. Дискета упала в корпус ниже. Она вставила следующую… И так всю пачку.
Лет 10 назад (фактически, когда Рег.ру еще был стартапом) работал в Рег.ру, пока жил не в Москве. Причиной работы тогда на Рег.ру в Самаре было то, что они предоставляли, в общем-то, неплохие зарплаты на региональном рынке. Как сейчас, не знаю, но предполагаю что аналогично.
Это скорее всего и является причиной работы в компании многих. На региональных рынках труда в ИТ, в общем, не разбежишься, особенно если ты Junior. А как народ дорастает до Middle/Senior, может и сваливают.
Да, я, честно говоря, тоже не могу понять, как это может нравиться.
У нас его использование проходило по разряду — мышки плакали, кололись, но продолжали есть кактус… Как только появилась альтернатива, все с облегчением на неё перешли
В гиттере проблемы с историей сообщений, с количеством новых (может, настраивается, но больше 100 не показывает), плюс он тормозной. Но на удивление достаточно стабильный. В плане рабочего чата его не пробовал, так что про интеграционные возможности по апи могу сказать только, что они есть.
Пользовались рокеткой примерно год (конец 2016-середина 2017). Потом всех слишком задолбали баги и пересели на mattermost (удивительно — где-то в начале 2017 рассматривали его — оказался глючным и сырым, к середине года ОЧЕНЬ сильно улучшился) Пока работал в компании (середина-конец 2017) — никаких претензий к mattermost не было. Пара незначительных глюков не в счет. Удобный, быстрый, хорошее мобильное приложение (рокет на мобильном это просто фууууу...). В общем, если бы решение зависело от меня, я бы его и сейчас в качестве корпоративного использовал. А рокетка слишком багованная. Может, сейчас получше, но лично я от её багов банально устал. И не я один.
Так кто же спорит. Я же не говорю, что статья или упомянутый инструмент плохи — ровно наоборот, просто не стоит вводить людей в заблуждение и мир (к счастью) не ограничивается Yandex'ом
Давайте определимся. Томита-парсером называется всего лишь ЛЮБОЙ GLR парсер. Обратитесь к ru.wikipedia.org/wiki/GLR-%D0%BF%D0%B0%D1%80%D1%81%D0%B5%D1%80. Называется он Томита-парсером из-за того, что сам GLR предложен Масару Томита, а вовсе не за работу с морфологией и т.п.
Томита-парсер яндекса — одна из реализаций GLR, с некоторыми встроенными плюшками (как и Наташа, хотя в плане последней не уверен).
Давайте отделять алгоритмы от реализаций :)
То, о чем говорили вы, это парсер КСГ с продвинутыми механизмами работы с морфологией, нормализацией, согласованием. А не GLR(Томита) парсер :)
Интересная вещь. Но вот некоторые комментарии в статье я бы подправил. Томита-парсеры для питона есть, и были. Например, Parglare, хотя под python 2.7 у него есть баг с обработкой unicode, возможно, будет исправлено позднее (под python 3 прекрасно работает) (подозреваю, что не только он, скорее всего любой GLR-парсер (или PEG) работающий под python3 не будет иметь проблем с русским языком).
Другое дело, не было инструмента с комплектом правил, заточенных под парсинг русских ФИО/дат/адресов — с этим спорить не буду (сам не сталкивался). В любом случае, хорошая статья, спасибо.
Вообще, на мой взгляд, подход будет жизнеспособным только при инкрементально наращиваемой сложности.
Задумываешь много, начинаешь с малого, там, где оно стыкуется с «много» ставишь заглушки. Чувствуешь в себе силы, снимаешь часть заглушек, делаешь реальные вещи. И т.д. и т.п. Как капуста, с кочерыжки к последним листкам. Просто иначе есть шанс получить кадавра, к примеру, с продвинутым паффайндингом, но без графики вообще, или с ровно одной картой, на которой этот паффайндинг работает. И опустившиеся руки.
На мой взгляд, мораль статьи как раз в том, чтобы не потерять запал из-за того что «еще столько надо сделать». Слона надо есть кусочками.
Спасибо за содержательный коментарий.
Моё знакомство с ANTLR было знакомством нуба. С точки зрения такого нуба, для таких же нубов.
Соответственно, я попытался с ним познакомиться с налета, используя доки с гитхаба, с сайта, поиск по интересующим темам (конкретным, вроде, как обойти левую рекурсию) в интернете. Набредал на пдф-ки и несколько вопросов на stackoverflow. Оттуда же и сомнения в обратной совместимости, люди обсуждали список ключей парсера v2 и v3 и им было грустно.
Мануалы как таковые серьезно не искал, каюсь, наверное стоило. Вообще, идея была — программист берет абсолютно незнакомый инструмент, разбирается за пару часов, пишет работающий код. С этой точки зрения мне ANTLR не зашел. Вполне вероятно, я сам себе злобный буратино, однако, подозреваю, описанный мной сценарий — то, к чему будет стремиться среднестатистический программист, столкнувшись с подобной задачей.
Естественно, для того, чьё знакомство с инструментом заметно глубже мои слова напоминают детский лепет, но мой опыт с этим инструментом показал [мне], что он имеет несколько более высокий порог вхождения, чем я предполагал. Только и всего. Мне этого вывода было достаточно.
Спорить не буду, не математик. Возможно, да, возможно, есть какие-то нюансы.
По поводу трудности освоения инструментов — даже спорить не буду. НО. Лучше освоить инструмент, чем писать каждый раз велосипед, это моё ИМХО. Если у вас это вызывает сомнение, значит просто инструмент ненадлежащего качества. Тогда стоит написать ИНСТРУМЕНТ лучше. А не переписывать всякий раз с нуля :)
По поводу оптимизаций я имел в виду не ANTLR, а что-то наподобие ragel или re2c. То есть инструмент, оптимизирующий саму работу с КА при парсинге, за счет чего и сам парсинг будет быстрее.
Полагаю, все во многом зависит от алгоритма построения, он может существенно отличаться, все-таки. Как дойдут руки, сделаю бенч для python/json, по хорошему стоит взять несколько библиотек. В конце концов, никто не гарантирует, что создатели AST-парсеров не используют регулярки ВНУТРИ.
Таки с чего вы решили, что LL(k) сводимо к LL(1)?
Насчет матчасти — тоже довольно странный вывод. Нет, разумеется, можно все тупо зазубрить и писать программу, толком не понимая, что и почему, но «это не наш метод» (с). Лучше один раз понять, чем 10 раз запомнить (а мы все прекрасно помним, что запомненное без понимания выветривается из памяти весьма быстро).
Про лексеры пожалуй соглашусь. Но, пожалуй, они войдут в следующую статью цикла.
Насчет контекстно-зависимых — дааа? Сам я на лиспе не программирую, но, вроде бы, вот это: cuiwww.unige.ch/isi/bnf/LISP/BNFlisp.html Бнф-грамматика для Lisp.
Грамматика для того же питона так же в открытом доступе и, как я понимаю, используется при компиляции языка. Да и вообще, почти все ЯП неплохо укладываются в БНФ (иначе были бы проблемы с парсингом и компиляцией)
Про продолжение — если не будет других запросов, следующая статья будет обзорно именно по АЛГОРИТМАМ парсинга, ну, плюс, о лексерах. Основное — идеи, лежащие в основе каждого алгоритма. Если кому-то будет интересна математика, это уже отдельно.
Еще, не соглашусь с вашим призывом переписывать велосипед. Не нужно это, скорее даже вредно. Вроде бы есть (планирую попробовать чуть позже) разные «оптимизированные» парсеры общего назначения. Наверняка, там много своих ограничений, но тем не менее. И вероятность того, что ваш велосипед будет лучше я оцениваю как весьма низкую. Другое дело, если на вашем любимом ЯП нормальной библиотеки нет. Тогда да, вперед и с песней. И лучше с результатами на гитхабе, чтобы следующему не пришлось повторять.
Помню, сестра рассказывала, со слов бывшего мужа, который подрабатывал эникеем.
В некой конторе сломался floppy-дисковод 3-дюймовик. Забрали на ремонт, взамен поставили заглушку, помните, старенькие такие, формой повторяли «мордочку» floppy. Утром приходит на работу секретарша (именно ША!) Ближе к обеду звонок, паника в голосе — ваш дисковод сожрал у меня пачку дискет!
Приезжают и выясняют, что секретарша, увидев заглушку, применила творческий подход — пилочкой для ногтей (sic!) пропилила (!!) в заглушке отверстие для дискеты. Вставила. Дискета упала в корпус ниже. Она вставила следующую… И так всю пачку.
Это скорее всего и является причиной работы в компании многих. На региональных рынках труда в ИТ, в общем, не разбежишься, особенно если ты Junior. А как народ дорастает до Middle/Senior, может и сваливают.
Хотя конечно, вопрос, что вы от месенджера хотите.
У нас его использование проходило по разряду — мышки плакали, кололись, но продолжали есть кактус… Как только появилась альтернатива, все с облегчением на неё перешли
Томита-парсер яндекса — одна из реализаций GLR, с некоторыми встроенными плюшками (как и Наташа, хотя в плане последней не уверен).
Давайте отделять алгоритмы от реализаций :)
То, о чем говорили вы, это парсер КСГ с продвинутыми механизмами работы с морфологией, нормализацией, согласованием. А не GLR(Томита) парсер :)
Другое дело, не было инструмента с комплектом правил, заточенных под парсинг русских ФИО/дат/адресов — с этим спорить не буду (сам не сталкивался). В любом случае, хорошая статья, спасибо.
Задумываешь много, начинаешь с малого, там, где оно стыкуется с «много» ставишь заглушки. Чувствуешь в себе силы, снимаешь часть заглушек, делаешь реальные вещи. И т.д. и т.п. Как капуста, с кочерыжки к последним листкам. Просто иначе есть шанс получить кадавра, к примеру, с продвинутым паффайндингом, но без графики вообще, или с ровно одной картой, на которой этот паффайндинг работает. И опустившиеся руки.
На мой взгляд, мораль статьи как раз в том, чтобы не потерять запал из-за того что «еще столько надо сделать». Слона надо есть кусочками.
Моё знакомство с ANTLR было знакомством нуба. С точки зрения такого нуба, для таких же нубов.
Соответственно, я попытался с ним познакомиться с налета, используя доки с гитхаба, с сайта, поиск по интересующим темам (конкретным, вроде, как обойти левую рекурсию) в интернете. Набредал на пдф-ки и несколько вопросов на stackoverflow. Оттуда же и сомнения в обратной совместимости, люди обсуждали список ключей парсера v2 и v3 и им было грустно.
Мануалы как таковые серьезно не искал, каюсь, наверное стоило. Вообще, идея была — программист берет абсолютно незнакомый инструмент, разбирается за пару часов, пишет работающий код. С этой точки зрения мне ANTLR не зашел. Вполне вероятно, я сам себе злобный буратино, однако, подозреваю, описанный мной сценарий — то, к чему будет стремиться среднестатистический программист, столкнувшись с подобной задачей.
Естественно, для того, чьё знакомство с инструментом заметно глубже мои слова напоминают детский лепет, но мой опыт с этим инструментом показал [мне], что он имеет несколько более высокий порог вхождения, чем я предполагал. Только и всего. Мне этого вывода было достаточно.
Ахо, часть 1, djvu 6.2 мб -//-
По поводу трудности освоения инструментов — даже спорить не буду. НО. Лучше освоить инструмент, чем писать каждый раз велосипед, это моё ИМХО. Если у вас это вызывает сомнение, значит просто инструмент ненадлежащего качества. Тогда стоит написать ИНСТРУМЕНТ лучше. А не переписывать всякий раз с нуля :)
По поводу оптимизаций я имел в виду не ANTLR, а что-то наподобие ragel или re2c. То есть инструмент, оптимизирующий саму работу с КА при парсинге, за счет чего и сам парсинг будет быстрее.
Если вас чем-то описанный случай не устраивает, предложите простой use-case, может быть, добавлю
Насчет матчасти — тоже довольно странный вывод. Нет, разумеется, можно все тупо зазубрить и писать программу, толком не понимая, что и почему, но «это не наш метод» (с). Лучше один раз понять, чем 10 раз запомнить (а мы все прекрасно помним, что запомненное без понимания выветривается из памяти весьма быстро).
Про лексеры пожалуй соглашусь. Но, пожалуй, они войдут в следующую статью цикла.
Насчет контекстно-зависимых — дааа? Сам я на лиспе не программирую, но, вроде бы, вот это: cuiwww.unige.ch/isi/bnf/LISP/BNFlisp.html Бнф-грамматика для Lisp.
Грамматика для того же питона так же в открытом доступе и, как я понимаю, используется при компиляции языка. Да и вообще, почти все ЯП неплохо укладываются в БНФ (иначе были бы проблемы с парсингом и компиляцией)
Про продолжение — если не будет других запросов, следующая статья будет обзорно именно по АЛГОРИТМАМ парсинга, ну, плюс, о лексерах. Основное — идеи, лежащие в основе каждого алгоритма. Если кому-то будет интересна математика, это уже отдельно.
Еще, не соглашусь с вашим призывом переписывать велосипед. Не нужно это, скорее даже вредно. Вроде бы есть (планирую попробовать чуть позже) разные «оптимизированные» парсеры общего назначения. Наверняка, там много своих ограничений, но тем не менее. И вероятность того, что ваш велосипед будет лучше я оцениваю как весьма низкую. Другое дело, если на вашем любимом ЯП нормальной библиотеки нет. Тогда да, вперед и с песней. И лучше с результатами на гитхабе, чтобы следующему не пришлось повторять.