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

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

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

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

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

Ищите "‹TAG" границу слова ноль или более чего-то, что не является '>', за которым следует '>' запомнить ноль или более чего-то, останавливаясь на первом "‹/TAG›"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Точно так же вы не построите 30-этажное здание без крана где-то там.

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

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

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

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

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

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

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

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

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

LOOK FOR "<TAG"

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

THEN ZERO-OR-MORE SOMETHING REMEMBERED

THEN NEAREST "</TAG>"

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

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

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

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

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

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

Затем, я думаю, возобладала идея UNIX «сделай все, что можешь, в одной строке». После улучшений в сценариях sed и grep регулярные выражения приобрели новые возможности, но сокращенные обозначения для них. Ларри Уолл включил их в Perl в качестве общего инструмента для разбора текста. Я предполагаю, что он сохранил компактность для однострочников, которые все еще были важны для Perl. И были сокращенные имена для общих классов символов, и еще больше мощности требовалось и давалось регулярным выражениям. Конечно, поскольку Perl также был языком модулей, синтаксис регулярных выражений также работал в блоках операторов и использовал более широко известный синтаксис.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из модуля perl Regexp::English :

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

    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";
            }
    }

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