Почему люди защищают синтаксис регулярных выражений?

Еще одна проблема с регулярным выражением заключается в том, что существует множество его разновидностей. .Net regex vs php regex vs другое регулярное выражение, все выглядят одинаково, но не дают одинакового результата (иногда вообще нет результата).

Посмотрите на другую сторону вопроса: как бы вы спроектировали новый синтаксис, который воплощал бы все функции, согласованность, лаконичность и надежность как регулярное выражение, но был бы более удобным для программистов?

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

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

Синтаксис регулярных выражений таков, потому что это действительно все, что вам нужно для полного описания поведения, которое вы ищете.

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

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

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

Вам следует рассматривать регулярные выражения как высокопроизводительные электроинструменты (я имею в виду электроинструменты в смысле строительной индустрии).

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

Точно так же нельзя построить 30-этажное здание без крана где-нибудь.

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

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

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

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

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

• Это совсем не похоже на код-гольф. Я не уверен, что вы там связаны. Почему бы не пожаловаться на указатели или что-то еще, используя тот же аргумент?

• Компактность регулярного выражения не имеет ничего общего с плохими именами переменных. Переменная с именем c может быть чем угодно. Синтаксис регулярного выражения не является ни двусмысленным, ни расплывчатым. Он точно описывает его узор.

• Это DSL. Так что, если это так? Вы когда-нибудь пробовали делать сложные вещи на SQL? Это тоже большой беспорядок. То, что одно и то же требует большего набора текста и синтаксиса, не улучшает ситуацию. У большинства людей, которых я обучаю, есть проблемы с регулярными выражениями, потому что они не привыкли думать и разрабатывать шаблоны, а не потому, что синтаксис экзотичен.

• Это легко понять, если вы это знаете. Что ж, это так. Электроинструменты не оптимизированы для новичков или людей, не желающих учиться. Я не жалуюсь на круглые скобки Lisp, но я не возражаю против синтаксиса регулярных выражений.

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

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

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

• Переподготовка и переоборудование: он приобрел огромное количество поклонников, и его корни слишком глубоки для капитального ремонта, даже если кто-то этого захочет. Люди выучили тайные правила и разработали свой набор трюков, сообщества и инструменты (я подключаю Expresso).
• Обширная поддержка: текущий синтаксис широко поддерживается на разных платформах .. переписать этот уровень поддержки - огромная задача даже если вы сбрасываете со счетов монументальную задачу написания собственного движка и обработки всех дополнительных случаев
• Reg Exp вряд ли изменится Наконец, что наиболее важно, RegExp не может быть приравнен к коду w.r.t. читаемость. Лично я использую регулярное выражение экономно и для быстрых разрезов, когда его преимущества перевешивают преимущества. (например, внутренний инструмент для преобразования электронной таблицы Excel клиента в формат XML, разработанный разработчиком). Регулярные выражения не нужно поддерживать и изменять ... если они очень сложные ... маскируют запах с помощью комментария (и это должно быть только один раз). Если вы обнаружите, что регулярное выражение регулярно изменяется (или если на вашем рабочем месте никто не знает регулярных выражений), вероятно, это был плохой выбор, и вам следует перейти на обычный код.

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

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

«как насчет всех очень простых для понимания, некомпактных, не загадочных и, смею сказать, красивых доменных языков, таких как SQL или LINQ?»

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

<TAG\b[^>]*>(.*?)</TAG>

Ищите «<TAG» - границу слова, равную нулю или более того, что не является «>», за которым следует «>», запоминайте ноль или более чего-либо, останавливаясь на первом «</TAG>»

Это довольно простое регулярное выражение. Действительно ли английскую форму легче понять? Не могли бы вы сделать лучше?

Регулярные выражения трудно читать, но так же трудно объяснить то, что вы от них хотите.

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

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

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

Почему у нет есть язык, на котором можно писать

LOOK FOR "<TAG"

THEN WORDBOUNDARY THEN ZERO-OR-MORE NOT('>') FOLLOWED-BY '>'

THEN ZERO-OR-MORE SOMETHING REMEMBERED

THEN NEAREST "</TAG>"

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

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

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

Затем я думаю, что пришла идея UNIX-do-all-you-can-in-a-one-line. После улучшений в сценариях sed и grep регулярные выражения приобрели новые возможности, но для них были сокращены обозначения. Ларри Уолл включил их в Perl как общий инструмент для анализа текста. Я предполагаю, что он сохранил компактность для одинарных строк, которые все еще были важны для Perl. И были сокращенные имена для общих классов символов, и еще больше возможностей было запрошено и дано регулярным выражениям. Конечно, поскольку Perl также был языком модулей, синтаксис регулярных выражений также работал в блоках операторов и использовал синтаксис, который был более широко известен.

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

Интересно, что при достаточно ясном синтаксисе для многословной версии Эмброуза кто-нибудь мог бы предложить модуль для Perl, который мог бы взять подробное регулярное выражение и «скомпилировать» его в компактное регулярное выражение, которое понимает Perl, используя более простые регулярные выражения через overload::constants или, возможно, Грамматика Parse::RecDescent.

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

Я обнаружил, что они менее читабельны, чем эквивалентные регулярные выражения.

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

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

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

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

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

Если вас отталкивает только синтаксис, возможно, вам стоит подумать о комбинаторах синтаксического анализатора в Haskell. Они могут выражать надмножество одних и тех же идей и иметь более явный синтаксис.

Pyparsing (http://pyparsing.wikispaces.com/Examples) - это библиотека Python, которая позволяет легко писать выражения, подобные регулярным выражениям, которые легко читаются, например, эти строки, которые будут анализировать «Hello, World!»:

from pyparsing import Word, alphas
greet = Word( alphas ) + "," + Word( alphas ) + "!"
greet.parseString("Hello, World!")

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

Другие намекали на это, но стоит прямо заявить:

Обычные языки не похожи на языки программирования. Они ближе к математической нотации.

Компактность и причудливость больше являются результатом попытки вывести точную нотацию из символов ASCII, чем преднамеренной попыткой краткости или запутывания.

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

Из модуля Perl Regexp :: английский:

Regexp::English provides an alternate regular expression syntax, one that is slightly more verbose than the standard mechanisms. In addition, it adds a few convenient features, like incremental expression building and bound captures.

    use Regexp::English;

    my $re = Regexp::English
            -> start_of_line
            -> literal('Flippers')
            -> literal(':')
            -> optional
                    -> whitespace_char
            -> end
            -> remember
                    -> multiple
                            -> digit;

    while (<INPUT>) {
            if (my $match = $re->match($_)) {
                    print "$match\n";
            }
    }