Комментарии 205
Идея-то хорошая, но эпик фэил ее в том, что есть сильная неоднозначность. Чем хорош «ненатуральный» язык, так это своей однозначностью.
^ намного проще запомнить чем startOfLine и есть уверенность, что не напишешь
Мы именно по этой причине в свое время не осилили выучить 1С, хотя сильно и честно старались:)
^ намного проще запомнить чем startOfLine и есть уверенность, что не напишешь
var tester = VerEx()
.linestart()
.afterthis( "http" )
.probably( "s" )
.andnnow( "://" )
.possible( "www." )
.anythingexcept( " " )
.endofline();
Мы именно по этой причине в свое время не осилили выучить 1С, хотя сильно и честно старались:)
Кстати эти вербальные выражения на 1С должны смотреться эпично…
А проблема неоднозначности легко решается шпаргалкой, распечатанной и повешенной на стену.
А проблема неоднозначности легко решается шпаргалкой, распечатанной и повешенной на стену.
Тестер = ВербальноеВыражение.НачалоСтроки().Затем(«http»).Возможно(«s»).Затем("://").Возможно(«www.»).ВсеКроме(" ").КонецСтроки();
Результат = Тестер.Проверить(ВозможноURL);
чего эпичного? достаточно понятно, вполне реализуемо.
написать что ль на досуге?
Результат = Тестер.Проверить(ВозможноURL);
чего эпичного? достаточно понятно, вполне реализуемо.
написать что ль на досуге?
Достаточно лаконично.
Просто у меня код на 1С ассоциируется с каким то боярским языком, простите. Не хочу никого обидеть…
Что то типа:
глаголСайтоместо = Ревизор.Начати().Опосля(«http»).Може(«s»).Опосля("://").Може(«www.»).Свене(" ").Аминь();
Результат = Словесность.Блюсти(глаголСайтоместо);
Просто у меня код на 1С ассоциируется с каким то боярским языком, простите. Не хочу никого обидеть…
Что то типа:
глаголСайтоместо = Ревизор.Начати().Опосля(«http»).Може(«s»).Опосля("://").Може(«www.»).Свене(" ").Аминь();
Результат = Словесность.Блюсти(глаголСайтоместо);
Достают такие упоминания, не поверите, как. Почему у американцев C# или Java подобных ассоциаций не вызывает?
Полно русских(это важно!) программистов, впадающих в ступор от кода на 1С, но почему-то я не видел ни одного англоязычного программиста, который бы впадал в ступор от любого ЯП с английским синтаксисом. К чему бы это?
Я вот рад, что на меня ступор не нападает лишний раз, я и русский код, и английский одинаково легко читаю.
Полно русских(это важно!) программистов, впадающих в ступор от кода на 1С, но почему-то я не видел ни одного англоязычного программиста, который бы впадал в ступор от любого ЯП с английским синтаксисом. К чему бы это?
Я вот рад, что на меня ступор не нападает лишний раз, я и русский код, и английский одинаково легко читаю.
Так, может, дело в 1С, а не в русском/английском языке? Я видел другие, не такие популярные языки, от которых лично я не плевался.
Может и в 1с. Что на ваш взгляд конкретно не так в 1с?
Частовстречаемые непроизносимые идентификаторы плюс отсутствие согласования слов, о которое постоянно спотыкается взгляд.
Вероятно это привычка. Я одинаково хорошо читаю код 1с и код C#. Но на C# изначально было переходить сложно.
С чего?
Хм, да вообщем потому же почему прогерам на стандартных языках сложно перейти на 1с.
В моем случае с C# — синтаксические отличия, чуть более строгая типизация, интуитивно непонятный текст.
Последнее наиболее сложное. Читая код 1с, можно из названий методов и переменных хотя бы примерно понять что код делает. Тоже самое в C# более трудная задача — нужно знать английский. А ведь еще транслит может быть.
В моем случае с C# — синтаксические отличия, чуть более строгая типизация, интуитивно непонятный текст.
Последнее наиболее сложное. Читая код 1с, можно из названий методов и переменных хотя бы примерно понять что код делает. Тоже самое в C# более трудная задача — нужно знать английский. А ведь еще транслит может быть.
Возможно, многие со мной не согласятся. Но знание английского необходимо в любом случае. Не важно на каком языке вы пишите.
Как писалось в одной хорошей книге: «Надо писать программы не на языке, а при помощи языка». Поэтому не важно на каком языке написана программа, главное, что она решает необходимые задачи, её легко прочитать и править (не только вам).
Как писалось в одной хорошей книге: «Надо писать программы не на языке, а при помощи языка». Поэтому не важно на каком языке написана программа, главное, что она решает необходимые задачи, её легко прочитать и править (не только вам).
Имело в виду «с какого языка сложно переходить на C#?». Я так понял 1С был первым языком? Первый раз с таким человеком сталкиваюсь :)
Да, 1с первый язык который я понял и на котором смог программировать. До 1с пытался что-то делать на c++, но безуспешно.
Как это необычно. Я начинал с Builder C++ и Delphi.
Ещё за всё время я сталкивался с некоторыми языками (приходилось читать и иногда чуть-чуть править), VB, C#, Python, Java. Но в данный момент очень много пишу на PHP и JS.
Когда мне один раз пришлось столкнуться с 1С (тесотвое задание по фрилансу), я открыл скрипт, попробовал что-то понять. Это далось мне с очень большим трудом и большим количеством запросов в поисковике. Надо было изменить там код так, чтобы он работал так, как написано в задании. По словам того, кто давал это задание, надо было изменить что-то толи в цикле, толи в условиях, сейчас уже не помню.
Я промудохался с этим файлом 2 часа, но так и не понял в каком месте нужно сделать изменения (правильные изменения), чтобы работало как надо и без ошибок. Я плюнул, сказал тому мужику «Сами мучайтесь со своим 1С» и мы с ним распрощались. Ещё он сказал, что я далеко не первый, кто так отреагировал=) Вот с тех пор у меня остался жутко плохой осадок от 1С.
Ещё за всё время я сталкивался с некоторыми языками (приходилось читать и иногда чуть-чуть править), VB, C#, Python, Java. Но в данный момент очень много пишу на PHP и JS.
Когда мне один раз пришлось столкнуться с 1С (тесотвое задание по фрилансу), я открыл скрипт, попробовал что-то понять. Это далось мне с очень большим трудом и большим количеством запросов в поисковике. Надо было изменить там код так, чтобы он работал так, как написано в задании. По словам того, кто давал это задание, надо было изменить что-то толи в цикле, толи в условиях, сейчас уже не помню.
Я промудохался с этим файлом 2 часа, но так и не понял в каком месте нужно сделать изменения (правильные изменения), чтобы работало как надо и без ошибок. Я плюнул, сказал тому мужику «Сами мучайтесь со своим 1С» и мы с ним распрощались. Ещё он сказал, что я далеко не первый, кто так отреагировал=) Вот с тех пор у меня остался жутко плохой осадок от 1С.
Излагайте претензии. У меня их полно, например, но к платформе и фреймворку, а не к русскому синтаксису(который, впрочем, вполне может быть и английским).
У меня особых претензий нет, просто выглядит по дурацки непривычно.
Хотя разработчиков языка я тоже могу понять, так как сам сильно страдаю, когда приходится придумать название переменной, в которой хранится какое то бухгалтерское значение. Приходится выбирать между транслитом или малораспространенным английским словом.
А чтобы не было переключений раскладки постоянно, им пришлось и сами reserved words делать кириллическими.
Думаю ход рассуждений 1Сников был какой то такой…
Хотя разработчиков языка я тоже могу понять, так как сам сильно страдаю, когда приходится придумать название переменной, в которой хранится какое то бухгалтерское значение. Приходится выбирать между транслитом или малораспространенным английским словом.
А чтобы не было переключений раскладки постоянно, им пришлось и сами reserved words делать кириллическими.
Думаю ход рассуждений 1Сников был какой то такой…
>просто выглядит по дурацки непривычно.
Это обычно и есть ключевой момент всех претензий. Надо ли тут упоминать синдром утёнка? :)
Это обычно и есть ключевой момент всех претензий. Надо ли тут упоминать синдром утёнка? :)
Думаю выбор кириллицы скорее обусловлен необходимостью быстрого и массового распространения платформы. В конце концов даже обычный бух знакомый с программированием весьма посредственно, способен сделать в своей конфигурации небольшие изменения. Русскоязычный синтаксис, названия методов и переменных дают возможность понять код малоподготовленному человеку.
> У меня особых претензий нет, просто выглядит по дурацки непривычно.
Аналогичные ощущения когда переходишь с русскоязычного синтаксиса на англоязычный.
> У меня особых претензий нет, просто выглядит по дурацки непривычно.
Аналогичные ощущения когда переходишь с русскоязычного синтаксиса на англоязычный.
удалено
Думаю выбор русского скорее связан с выбором идентификаторов для документов, справочников, регистров, табличных частей реквизитов, ресурсов и т.д. Когда знаешь, что тебе нужно создать счет фактуру полученную или авансовый отчет, то проще так и писать СчетФактураПолученный, АвансовыйОтчет, чем думать о том, как какой-нибудь бухгалтерский термин перевел на английский какой-нибудь программист.
>>В конце концов даже обычный бух знакомый с программированием весьма посредственно, способен сделать в своей конфигурации небольшие изменения.
Я пока таких бухов не встречал))
>>В конце концов даже обычный бух знакомый с программированием весьма посредственно, способен сделать в своей конфигурации небольшие изменения.
Я пока таких бухов не встречал))
Отчасти потому что английский предполагает согласование слов прежде всего с помощью других слов или их порядка, а русский с помощью изменений самих слов. А ЯП как правило не дают такой свободы и получается что-то вроде
если (коллекция.пуст<b>ой</b>()) или если (массив.пуст<b>ое</b>()) или если(дерево.пуст<b>ая</b>()), что несколько режет глаз. Ну и длина слова в русском в среднем длиннее чем в английском.Это вкусовщина, есть же Intellisence, окончания не нужно дописывать, сами подставятся. Считать английский язык идеальным для программирования — опрометчиво. Там, например, внутренняя флексия есть — неправильные глаголы.
проблема надуманная на самом деле. после погружения в язык, программист начинает думать о том, что метод делает, а не про то, как он выглядит. Какой-нибудь strcpy() для простого англоязычника выглядит не менее странно, чем СтрДлина(). В конце концов, и на ассемблере люди пишут.
Код на 1С иногда выглядит забавно, да, про всякие «КОНЕЦ КАК Поле» или «ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент» давно байки сложены
Код на 1С иногда выглядит забавно, да, про всякие «КОНЕЦ КАК Поле» или «ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент» давно байки сложены
названия методов можно придумать любые, в 8й версии модули юникодные, так что хоть иероглифами, хоть арабской вязью называйте, не проблема, если вам так удобнее воспринимать код.
Мистяне на хабре :) Подсветки 1С-а не хватает, небось? )
Я соглашусь в том, что многие операторы регулярных выражений запомнить проще, чем их реализации в таком виде.
Но для начинающих разработчиков подобные библиотеки — это клад.
Это только потом начинающие разработчики вырастут из джуниоров и поймут, что тягать по библиотеке для каждой тривиальной задачи — это не совсем то (читай как «совсем не то»).
А так, я думаю, что подобная библиотека поможет джуниору хотя бы не начать плеваться от фразы «регулярное выражение».
Но для начинающих разработчиков подобные библиотеки — это клад.
Это только потом начинающие разработчики вырастут из джуниоров и поймут, что тягать по библиотеке для каждой тривиальной задачи — это не совсем то (читай как «совсем не то»).
А так, я думаю, что подобная библиотека поможет джуниору хотя бы не начать плеваться от фразы «регулярное выражение».
А так, я думаю, что подобная библиотека поможет джуниору хотя бы не начать плеваться от фразы «регулярное выражение».Здесь согласимся, но! нам в свое время помогло руководство, где грубо говоря слева было написано вербальное изложение, а справа — регулярное.
Как люди глубоко ленивые и искренне веряющие в лозунг «лень двигатель прогресса», мы быстро усвоили что те что справа — короче и быстрее пишутся:) Однако либу такую для реального использования мы бы не стали брать…
Хотя да, признаем, вербальная запись сильно помогла в свое время понять регулярки.
Извините, пожалуйста, за оффтопик, а у вас раздвоение и\или более личности или живность какая в организме? Обидеть не хочу, честное слово, просто любопытно.
Судя по профилю, этот аккаунт используется не одним лицом.
А судя по описанию профиля, и по качеству показанной CMS, эти лица слегка опупевшие.
С интересом посмотрим на Вашу CMS образца 2004 года, что бы понять насколько Вы действительно можете судить о чужой опупешности:)
Я бы начал с того, что не выдавал бы патченный php nuke за собственную разработку.
Во-вторых не стал бы хвастаться системой, написанной в 2004 спустя 9 лет, а написал бы что-то более современное и симпатичное — с более чем 10-ти летним опытом веб-программирования, это не заняло бы больше недели.
Ну и не стал бы сидеть всей командой на хабре с одного аккаунта — думаю за столь огромное время накопилось немало историй, которые были бы интересны сообществу.
Свой первый сайт я тоже сделал в 2004, но не считаю что этим стоит гордиться — технологии тогда были немного другие, а HTML теги писали капсом.
Во-вторых не стал бы хвастаться системой, написанной в 2004 спустя 9 лет, а написал бы что-то более современное и симпатичное — с более чем 10-ти летним опытом веб-программирования, это не заняло бы больше недели.
Ну и не стал бы сидеть всей командой на хабре с одного аккаунта — думаю за столь огромное время накопилось немало историй, которые были бы интересны сообществу.
Свой первый сайт я тоже сделал в 2004, но не считаю что этим стоит гордиться — технологии тогда были немного другие, а HTML теги писали капсом.
Я бы начал с того, что не выдавал бы патченный php nuke за собственную разработку.Мы и не выдаем. На главной первой же строкой в основном блоке написано что это «патченая пхпнюке».
Остальное то что Вы написали — страннейшие вещи.
«хвастаться системой, не сидеть командой, гордиться разработкой» — откуда Вы это взяли? Где мы хвастались? В чем стыд сидеть командой с одного акка? Где написано что мы гордимся?
У нас в профиле просто указан наш сайт. Больше ничего. Всё остальное — плод Ваших домыслов и мы искренне не понимаем откуда это у Вас и зачем.
А из объективной критики — начал бы с поика по сайту и 404 ошибки — если вы понимаете о чем я, товарищи «пишите на почту».
«больше 10 лет в веб-программинге, больше 15 лет в программировании.» — нихрена не значит, если даже свою витрину нормально оформить не в состоянии, потому и «Присутствует заинтересованность: крупных проектах «с нуля» по ТЗ (бюджет от 5,000$) и в почасовой работе (от 40$ в час).» — слегка опупевшие заявления.
Может вы и хорошие ребята — лично я вас не знаю, но качество вашей CMS на уровне студентов-первокурсников образца 2005 года.
«больше 10 лет в веб-программинге, больше 15 лет в программировании.» — нихрена не значит, если даже свою витрину нормально оформить не в состоянии, потому и «Присутствует заинтересованность: крупных проектах «с нуля» по ТЗ (бюджет от 5,000$) и в почасовой работе (от 40$ в час).» — слегка опупевшие заявления.
Может вы и хорошие ребята — лично я вас не знаю, но качество вашей CMS на уровне студентов-первокурсников образца 2005 года.
«больше 10 лет в веб-программинге, больше 15 лет в программировании.» — нихрена не значит, если даже свою витрину нормально оформить не в состоянии, потому и «Присутствует заинтересованность: крупных проектах «с нуля» по ТЗ (бюджет от 5,000$) и в почасовой работе (от 40$ в час).» — слегка опупевшие заявления.
Мы действительно больше 10 лет в вебе и больше 15 лет в программинге, мы выполняем заказы на ставке от 40уе в час при почасовой оплате и нам не интересна ставка ниже.
Что такого «опупевшего» в том, что бы изложить факты у себя в профиле? Вопрос разумеется риторический.
Боже мой.
www.edogs.ru/modules.php?name=edogssitemap
52 запроса к БД?????
Для формирования карты сайта.
Как после ТАКОГО можно предлагать услуги «оптимизация кода для снижения нагрузки».
Пипец. 52 запроса.
Неплохо бы еще капчу поставить нормальную, чтобы спамеры не лезли. www.edogs.ru/modules.php?name=News&file=article&sid=26
Но ведь люди, предлагающие «аудит безопасности, нахождение и устранение проблем» и так без моих советов все знают, я так думаю.
Про такие мелочи, вроде того что лого не ссылается на главную и верстку таблицами я просто промолчу.
www.edogs.ru/modules.php?name=edogssitemap
52 запроса к БД?????
Для формирования карты сайта.
Как после ТАКОГО можно предлагать услуги «оптимизация кода для снижения нагрузки».
Пипец. 52 запроса.
Неплохо бы еще капчу поставить нормальную, чтобы спамеры не лезли. www.edogs.ru/modules.php?name=News&file=article&sid=26
Но ведь люди, предлагающие «аудит безопасности, нахождение и устранение проблем» и так без моих советов все знают, я так думаю.
Про такие мелочи, вроде того что лого не ссылается на главную и верстку таблицами я просто промолчу.
Поймите одно, Вы пытаетесь втиснуться нас в свои стандарты — раз указан сайт, значит он предмет для гордости, люди им хвастаются, считают его своей витриной, демонстрацией качества CMS, там должно быть минимум запросов и т.д. и т.п…
Учитывая то, что у Вас сайта в профиле нет и нашу просьбу показать Ваши творения 2004 года Вы проигнорировали, видимо это рассуждения об устрицах которые Вы мечтаете скушать:)
У нас же это просто сайт 2004 года.
Не предмет для гордости, мы им не хвастаемся, витриной его не считаем, качество CMS на нем не демонстрируем и нас нисколько не напрягают огрехи на нем.
Это просто часть нашей истории, которая была и которая в прошлом. Не более и не менее.
Зачем пытаться вложить в него тот смысл, которого в нем нет, а потом радостно топтать этот Вами же вложенный в него смысл:) Ведь посмотрите на дискуссию выше — все Ваши претензии относятся к тем вещам, которые Вы же сами нам и приписали.
Учитывая то, что у Вас сайта в профиле нет и нашу просьбу показать Ваши творения 2004 года Вы проигнорировали, видимо это рассуждения об устрицах которые Вы мечтаете скушать:)
У нас же это просто сайт 2004 года.
Не предмет для гордости, мы им не хвастаемся, витриной его не считаем, качество CMS на нем не демонстрируем и нас нисколько не напрягают огрехи на нем.
Это просто часть нашей истории, которая была и которая в прошлом. Не более и не менее.
Зачем пытаться вложить в него тот смысл, которого в нем нет, а потом радостно топтать этот Вами же вложенный в него смысл:) Ведь посмотрите на дискуссию выше — все Ваши претензии относятся к тем вещам, которые Вы же сами нам и приписали.
Ну ладно вам, не ссорьтесь :( Всем добра!
Странно. Мне написало, что не 52 запроса, а 62!
Они ещё ссылками барыжат на этом сайте. Ну и гугловский рекламный блок, наверно, все заметили.
По моим прикидкам, они имеют с этого сайта, ну максимум тысячи 3 в месяц РУБЛЕЙ. Как-то это странно, учитывая, что их ценник от $40/час.
Немного не адекватный ход, как мне кажется.
Я бы вообще постыдился ставить такой сайт в профиль.
И я попробовал понять откуда взялась такая цифра и насчитал ну максимум запросов 15, которые нужны для отображения этой страницы. Но и то некоторые вещи я бы заменил статикой, поэтому уверен, что там и меньшим количеством запросов можно обойтись.
P.S.: И на сайтах в ссылках снизу тоже ссылками барыжат.
Не, я бы точно постыдился ЭТО ставить в профиль. Хотя у самого лысый WP стоит, всё никак не могу найти время нарисовать шаблон и вести уже этот чёртов блог=)
Открытие страницы: 0,009 секунды и 62 запросов к базе данных! DB time is:0,001589! DB connect time is: 0,001
Они ещё ссылками барыжат на этом сайте. Ну и гугловский рекламный блок, наверно, все заметили.
По моим прикидкам, они имеют с этого сайта, ну максимум тысячи 3 в месяц РУБЛЕЙ. Как-то это странно, учитывая, что их ценник от $40/час.
Немного не адекватный ход, как мне кажется.
Я бы вообще постыдился ставить такой сайт в профиль.
И я попробовал понять откуда взялась такая цифра и насчитал ну максимум запросов 15, которые нужны для отображения этой страницы. Но и то некоторые вещи я бы заменил статикой, поэтому уверен, что там и меньшим количеством запросов можно обойтись.
P.S.: И на сайтах в ссылках снизу тоже ссылками барыжат.
Не, я бы точно постыдился ЭТО ставить в профиль. Хотя у самого лысый WP стоит, всё никак не могу найти время нарисовать шаблон и вести уже этот чёртов блог=)
Хотя у самого лысый WP стоит
с этого начинать надо, вместо того чтобы самоутверждаться за счет критики в чужой адрес, вы бы лучше полезное что-то сделали.
че все на идогов наехали вдруг
Ничего личного, просто странно как-то всё это. Я про то, что у них написано в профиле и про то, что видно по ссылке в их же профиле чуть ниже.
Например?
вы бы лучше полезное что-то сделали
Например?
вы так подробно проанализировали их рекламу на сайте, посчитали все возможные и невозможные доходы, а сами
всё никак не могу найти время нарисовать шаблон и вести уже этот чёртов блог=)
Одно дело рекламу на сайте с низкой посещаемостью размещать и ссылками барыжить, а другое дело создать уникальный и оригинальный дизайн для блога, и писать на интересные и полезные темы. Тем более, что помимо этого желания есть ещё и работа и хобби, ещё я не мало времени трачу на самосовершенствование и изучение вещей, которые кажутся мне интересными. Грубо говоря у меня просто пока нет времени на эту мелочь ;)
И почему же все возможные и невозможные доходы?) Страниц там мало, тИЦ 10, сомневаюсь, что посещаемость (не учитывая сегодняшнего мини-хабраэффекта) доходит до отметки в 1000 уников в месяц. Отсюда и цифра, но и она весьма завышенная, на мой взгляд ;)
Всем мир ;)
И почему же все возможные и невозможные доходы?) Страниц там мало, тИЦ 10, сомневаюсь, что посещаемость (не учитывая сегодняшнего мини-хабраэффекта) доходит до отметки в 1000 уников в месяц. Отсюда и цифра, но и она весьма завышенная, на мой взгляд ;)
Всем мир ;)
По моим прикидкам, они имеют с этого сайта, ну максимум тысячи 3 в месяц РУБЛЕЙ. Как-то это странно, учитывая, что их ценник от $40/час.Карму нам тут конечно изрядно сливают за каждый ответ, но все-таки на это ответим.
Немного не адекватный ход, как мне кажется.
Мы реально не понимаем, почему из-за ложного чувства стыда, мы должны терять 100 (допустим, возьмем Вашу цифру за базу) баксов в месяц, снимая рекламу и/или ссылки с сайта.
Сайт у нас за последние 8 лет отнял дай бог час времени, как Вы уже обратили внимания, он 8 лет как заброшен. Доход? Ну допустим 8 лет * 12 месяцев * 100 баксов = 9600 баксов. Это платеж по ипотеке в течении года, например.
Или опять же — это 320 часов рабочего времени если считать по 30 баксов (8 назад мы не 40 стоили), т.е. по сути 2 месяца жизни. Которые у нас за счет этого сайта освободились для других дел — для опенсоурсных проектов в которых мы принимаем участие, для семьи, для отдыха.
Мы никому ничего не диктуем и не навязываем, упаси боже. Но упаси нас боже когда-нибудь из-за ложного чувства стыда выкинуть в топку этот пассивный доход.
Не, я бы точно постыдился ЭТО ставить в профильА мы не стыдимся своей истории:)
Я бы на вашем месте не стал оправдываться и просто убрал ссылку на злосчастный сайт из своего профиля, ваш доход от этого же не убавится. Всё что написано выше — это мнения других людей. Вы вправе не соглашаться с их мнением. И вы не обязаны это чужое мнение изменять.
И почему вы цены снизили? Демпингуете?
И почему вы цены снизили? Демпингуете?
Я бы на вашем месте не стал оправдыватьсяМы не оправдываемся, мы просто объяснили свою позицию. Поскольку нам показалось исходя из хода диалога, что она не вполне ясна. Ну а здесь все же солидный ресурс, поэтому посчитали нужным объяснить ее более развернуто. Каждый волен согласиться с ней или нет и мы ее ни в коем случае никому не навязываем.
На счёт цен догнал, можете не править меня. Вы усреднили цены за 8 лет.
Немного дизориентирует.
… (8 назад мы не 40 стоили)...
Немного дизориентирует.
просто убрал ссылку на злосчастный сайт из своего профиляЭто мы уже проходили на других ресурсах:)
В ходе дискуссии рано или поздно находился кто-нибудь, кто догадывался проассоциировать наш ник и сайт, даже когда сайт не был указан в профиле. После чего с радостным криком «ага, они скрывают свой позор» вываливал его на форум и диалог превращался примерно в то же, во что превратился тут, только еще с добавочным убераргументом «едоги свой сайт скрывают!»©
Поэтому пусть уж лучше будет.
Так теперь уже благодаря хабру уников тыщ на 5 побольше стало, я бы не стал убирать
Наоборот, поднял бы цену за час до 50 баксов
Наоборот, поднял бы цену за час до 50 баксов
Наверно китайцы.
Для начинающих разработчиков есть книги с совами и ламой.
С запоминанием всегда поможет автодополнение IDE. Другое дело, что пример приведен слишком простой. И даже он работает некорректно.
А если взять пример сложнее, то получится такая простыня кода, что регулярное выражение рядом с ней покажется благом.
А если взять пример сложнее, то получится такая простыня кода, что регулярное выражение рядом с ней покажется благом.
Intellisense и аналоги решают эту проблему полностью. Сейчас уже IDE без автокомплита надо поискать еще.
Неоднозначность возникает только если воспринимать это как естественный язык. Если же относится как к мнемонике для формальных правил, то ничем не хуже.
Это всего лишь способ превратить регулярные выражения из write-only в read-write инструмент и идея в целом мне очень нравится. Практическая применимость будет определяться конкретной реализацией API.
Это всего лишь способ превратить регулярные выражения из write-only в read-write инструмент и идея в целом мне очень нравится. Практическая применимость будет определяться конкретной реализацией API.
> .linestart()
> .afterthis( «http» )
> .probably( «s» )
то-есть в си вы пишете «writef», «freveal», «assignbuf»?
> .afterthis( «http» )
> .probably( «s» )
то-есть в си вы пишете «writef», «freveal», «assignbuf»?
> то-есть в си вы пишете «writef»
printf пишем:)
Но в целом мы Вашу мысль уловили и в чем-то даже согласны. Тут Вы сильно правы.
Однако, с си нам повезло, его мы начали учить раньше чем английский, поэтому во время его изучения эти термины не были для нас настолько «вербальными» конструкциями, как сейчас.
printf пишем:)
Но в целом мы Вашу мысль уловили и в чем-то даже согласны. Тут Вы сильно правы.
Однако, с си нам повезло, его мы начали учить раньше чем английский, поэтому во время его изучения эти термины не были для нас настолько «вербальными» конструкциями, как сейчас.
Да, было бы с автоподсказкой и автодополнением, типа Java в IDE, — было бы проще…
Не совсем понял — в чем проявляется неоднозначность 1С?
Мне кажется, что регулярные выражения — более мощный аппарат, чем эта поделка.
Зато снижает порог входа. Лично мне приходится писать регэкспы раз в год, не чаще.
Даже простейшие выражения приходится составлять с большим трудом и с тестированием в sandbox.
Даже простейшие выражения приходится составлять с большим трудом и с тестированием в sandbox.
отправляйтесь в летнюю школу перла, вас там быстро научат кодить на регекспах.
Еще чего… =)
Вам приходится писать регекспы не чаще раза в год именно потому, что вам сложно их использовать, и вы, естественно, решаете проблемы другими способами. Я же, как только освоил регулярки, сразу же стал активно использовать их в поиске и замене в текстовом редакторе. Просто нужно один раз разобраться, ничего сложного для IT'шника в них нет.
Использовать сложные регулярки для обработки обычных текстов или исходников как-то не очень хорошо, по-моему. Все равно нужно использовать обычный поиск по подстроке и контроля глазами что регулярка ничего не пропускает, но и лишнего не цепляет. Если, конечно, вы не знаете языки (документа и регулярок) в совершенстве и способны сходу написать регулярку, учитывающую все словоформы, включая выпадание и замену букв в некоторых формах или имя в функции в исполняемом коде, не считая комментариев (трех видов), имен переменных и констант и вхождений в строки.
Так никто вас не заставляет использовать сложные регулярки. Вы сами выбираете, когда их использовать, а когда — нет. Хотите — используйте на исходниках; боитесь что-то пропустить или регулярка получается слишком сложной — правьте вручную. Суть моего комментария была в том, что если вы не умеете обращаться с регулярками, или у вас это получается плохо, или вам редко попадаются такие задачи, которые хорошо решаются регулярками, то и пользоваться ими вы будете реже. Но, разумеется, не стоит из этого делать далеко идущие выводы о том, что регулярки не нужны.
Вот пример задачки, для которой я недавно использовал регуляки. Есть мобильное приложение, которое вызывает через JS методы в Java-классе (через Cordova). Захотелось автоматизировать процесс проверки (через процессор аннотаций), реализованы ли все API-функции в Java-коде, и наоборот — описаны ли в JS-коде все API-функции. Я бы мог всунуть в проект какой-нибудь парсер JavaScript, но мне это показалось перебором, поэтому я написал три короткие регулярки, вычленяющие имена методов из вызовов вида Cordova.exec(null, null, «имя класса с API», «имя метода», parameters). Работает быстро, и это важно — замедлять компиляцию через процессор аннотаций ой как не хочется (полноценный парсер всё испортит), ну и код работы с регулярками тривиален.
Вот пример задачки, для которой я недавно использовал регуляки. Есть мобильное приложение, которое вызывает через JS методы в Java-классе (через Cordova). Захотелось автоматизировать процесс проверки (через процессор аннотаций), реализованы ли все API-функции в Java-коде, и наоборот — описаны ли в JS-коде все API-функции. Я бы мог всунуть в проект какой-нибудь парсер JavaScript, но мне это показалось перебором, поэтому я написал три короткие регулярки, вычленяющие имена методов из вызовов вида Cordova.exec(null, null, «имя класса с API», «имя метода», parameters). Работает быстро, и это важно — замедлять компиляцию через процессор аннотаций ой как не хочется (полноценный парсер всё испортит), ну и код работы с регулярками тривиален.
Главное не пропускать факультативы, где учат читать получившееся.
Если человеку сложно осилить регулярки, то может тогда вообще не стоит этим заниматься ни в коем виде? )
По-моему, если надо написать регулярку раз в год, то можно без проблем восстановить память прочитав какую-нибудь памятку за 5 минут. Если же надо читать супер-мега-сложную регулярку раз в год и лень разбираться, можно без проблем попросить помощи.
Ну а если регулярки пишутся на регулярной основе и не могут осилиться, то + 1 к «может тогда вообще не стоит этим заниматься ни в коем виде?».
Когда мне нужно было решить 2-5 раз в год задачу, которая решается регэкспами, но я боялся ставить в свой код чёрный ящик и не знал как оно работает изнутри — я брал и писал парсинг руками. Посимвольно ползя по строке. Если бы код был на сях, то скорее всего он бы оказался оптимальнее использования регэкспов по скорости. А сейчас у всех какая-то тяга идти тут же в гугл и пытаться совладать с языком, который кажется магией, вместо подхода «не знаю как юзать вон то, но я не инженер что ли? Пиздa тебе, задача eбаная!»
Магия? Чёрный ящик? о_О Мы точно об одно и том же?
Одна из составляющих инженерного подхода — использовать готовые изделия, даже если их разработчик о подобном использовании и подумать не мог. Не тупо, конечно, использовать, а проверив применимость, но в программировании это обычно вопрос лишь времени программиста. В общем нагуглить регэксп, проверяющий валидность e-mail адреса, проверив, что он работает в обычных случаях и работает достаточно экономно, обычно много лучше, чем создавать свой парсинг, зарывшись в кучу RFC.
Это пока вы не знаете регулярных выражений они вам нужны раз в год. Я пока не знал их тоже раз в год использовал. А сейчас я их использую не реже нескольких раз в месяц.
«Если у вас есть проблема, и вы собираетесь решить ее с помощью регулярных выражений, то у вас уже две проблемы» © не_помню_кто
Всего в меру :)
Всего в меру :)
Да, можно сидеть и в ручную править текст, а можно один раз запустить замену по регулярному выражению.
У этой цитаты интересная история. Джеффри Фридл на эту тему написал неплохой топик. Советую ознакомится:
regex.info/blog/2006-09-15/247
на английском.
regex.info/blog/2006-09-15/247
на английском.
Ага. А еще если вы ими собираетесь парсить html, то это ужасно...
Думаю, отдельная мини-IDE для регулярок — с автоподсветкой синтаксиса, автопродолжением, автозакрытием скобок и прочим преферансом с поэтессами — не помешала бы;-) Ну или хотя бы плугин для обычной IDE…
У «поделки» есть существенное достоинство — это можно прочитать. Кто пробовал разобрать сложный регэксп, написанный кем-то другим — думаю, со мной согласится.
Так на поделке нельзя написать сложный регэксп.
Пробовал 16 килобайт реждексп понять (авто генерированный). Часа 3 ушло. Пришлось использовать ручку с 2 цветами;).
А вообще когда-то был тул (сейчас не могу подобрать ключевые слова для гугла), который перл реджекспы конвертировал в многострочные. Очень наглядно.
А вообще когда-то был тул (сейчас не могу подобрать ключевые слова для гугла), который перл реджекспы конвертировал в многострочные. Очень наглядно.
Звучит как «кому нужна линейка, если есть штангенциркуль»? Я согласен, что регэкспы полезней, и определённо, стоят изучения, но в скриптовании, как мне кажется, штука интересная.
А кто возьмет линейку, если под рукой штангенциркуль? Правда несколько условий из за не полного соответствия метафоры: человек умеет пользоваться штангенциркулем, надо измерить расстояние, а не провести линию.
Я например линейкой пользуюсь исключительно для проведения линий. Измерение: рулетка для больших расстояний, штангенциркуль для средних и микрометр для мелких.
А по теме: какая разница запомнить «startOfLine — это начало строки» или "^ — это начало строки"? Просто читается? Простые регулярные выражения тоже читаются просто. А если на этом языке наворотить сложное, то я не думаю, что его можно будет прочитать на раз. И даже не буду заострять внимание на прочтении кода другим программистом…
Мне кажется с регулярными выражениями сложность не в синтаксисе. А в самой их сути. Одна строчка обычно делает что-то «одно», а тут целая «программа» в одной строке.
Я например линейкой пользуюсь исключительно для проведения линий. Измерение: рулетка для больших расстояний, штангенциркуль для средних и микрометр для мелких.
А по теме: какая разница запомнить «startOfLine — это начало строки» или "^ — это начало строки"? Просто читается? Простые регулярные выражения тоже читаются просто. А если на этом языке наворотить сложное, то я не думаю, что его можно будет прочитать на раз. И даже не буду заострять внимание на прочтении кода другим программистом…
Мне кажется с регулярными выражениями сложность не в синтаксисе. А в самой их сути. Одна строчка обычно делает что-то «одно», а тут целая «программа» в одной строке.
Я не знаю, как у вас, а у меня при чтении регулярных выражений «глаза разбегаются», по крайней мере, если без подсветки. Что-то пропустил или увидел не то — смысл уже совсем другой. Язык-то не человеческий, без избыточности. Это и хорошо в смысле размеров записи, и плохо в смысле читабельности, потому что коррекции ошибок чтения никакой :)
Что касается линейки и штангенциркуля — вы правильно заметили, что зависит-то от задачи :) Пользованию линейкой практически не нужно учиться, и для простейших измерений она вполне себе годится. Кроме того, годится для проведения линий. Хотя в смысле измерений штангенциркуль несравнимо лучше. Но почему-то линейки всё ещё существуют)
Что касается линейки и штангенциркуля — вы правильно заметили, что зависит-то от задачи :) Пользованию линейкой практически не нужно учиться, и для простейших измерений она вполне себе годится. Кроме того, годится для проведения линий. Хотя в смысле измерений штангенциркуль несравнимо лучше. Но почему-то линейки всё ещё существуют)
Полностью согласен.
Только дополню, что в отличии от линейки этому виду записи регулярных выражений тоже надо учиться.
Может обычные регулярные выражения немного сложнее учить сначала, но в дальнейшем плюсы неоспоримы.
Мне кажется, что библиотека может найти только одну нишу — когда «не программисту» понадобилось регулярное выражение (впрочем, почему бы не написать обычное?). Любому программисту, который в будущем видит себя программистом, не стоит полагаться на такие решения.
Только дополню, что в отличии от линейки этому виду записи регулярных выражений тоже надо учиться.
Может обычные регулярные выражения немного сложнее учить сначала, но в дальнейшем плюсы неоспоримы.
Мне кажется, что библиотека может найти только одну нишу — когда «не программисту» понадобилось регулярное выражение (впрочем, почему бы не написать обычное?). Любому программисту, который в будущем видит себя программистом, не стоит полагаться на такие решения.
Любому программисту, который в будущем видит себя программистом, не стоит полагаться на такие решения.
Не был бы столь однозначным. Если регулярки пишешь раз в год, то такой синтаксис будет удобнее прежде всего читать через год. Да и префиксная форма записи выглядит более естественной как-то для большинства ЯП.
Сам уже врядли что-то подобное использовать буду, но лет 15 назад было бы полезно, думаю.
Если регулярки писать раз в год, то может прочитать и удобнее будет, но вот надо написать ещё одно а уже забылось, какой там был класс, как он работал. И всё приходится искать заново. Но информации по этому классу будет значительно меньше, чем по «чистым» регулярным выражениям.
Притом всё, что выучили за первый раз — на второй год осознается намного проще, а на третьем году — и мануал смотреть не придется. Конечно и к классу можно привыкнуть и запомнить, только вот пользы от него будет меньше.
А насчет
Тут акцент на «в будущем видит себя программистом». Регулярное выражение понадобится любому программисту, который работает хоть какое-то продолжительное время. И если год назад ты разобрался с их азами, то какая-то более сложная вещь сейчас будет проще.
Просто мне не кажется, что подход «выучить сейчас то, что по-проще и сделать, а когда понадобится более сложное — то учить с нуля» лучше, чем «выучить нужные основы сложного сейчас и сделать, а когда понадобится более сложное — то разбираться дальше». Естественно, что человеку, которому регулярное выражение нужно будет 1 раз за всю жизнь, не надо учить «чистые регвыр» — можно класс использовать, или знакомого попросить. Но вот «программисту, который в будущем видит себя программистом» регулярки ещё понадобятся.
Притом всё, что выучили за первый раз — на второй год осознается намного проще, а на третьем году — и мануал смотреть не придется. Конечно и к классу можно привыкнуть и запомнить, только вот пользы от него будет меньше.
А насчет
Любому программисту, который в будущем видит себя программистом
Тут акцент на «в будущем видит себя программистом». Регулярное выражение понадобится любому программисту, который работает хоть какое-то продолжительное время. И если год назад ты разобрался с их азами, то какая-то более сложная вещь сейчас будет проще.
Просто мне не кажется, что подход «выучить сейчас то, что по-проще и сделать, а когда понадобится более сложное — то учить с нуля» лучше, чем «выучить нужные основы сложного сейчас и сделать, а когда понадобится более сложное — то разбираться дальше». Естественно, что человеку, которому регулярное выражение нужно будет 1 раз за всю жизнь, не надо учить «чистые регвыр» — можно класс использовать, или знакомого попросить. Но вот «программисту, который в будущем видит себя программистом» регулярки ещё понадобятся.
Ключевой фактор — способен ли программист предугадать свое будущее. Регулярки достаточно универсальный инструмент для обработки текста, но специализированные обычно лучше по многим параметрам на своих задачах, даже если внутри они используют регулярки. И вполне может оказаться, что изучение вербальных выражений для примитивной фильтрации ввода и лексера для анализа принесет меньше потерь чем изучение регулярок и для того, и для другого.
Но информации по этому классу будет значительно меньше, чем по «чистым» регулярным выражениям
Это называется "положительная обратная связь", и никакого отношения к тому, хороша технология или плоха — не имеет. Плохая технология тоже может быть хорошо документирована. Нет, я не сказал, что регулярки однозначно плохи. Но если бы они действительно были всем хороши — думаю проект из топика никогда бы не возник.
А кто возьмет линейку, если под рукой штангенциркуль?
Я :) Далеко не всегда нужна точность большая, а линейка удобнее и компактнее.
Значит вы недостаточно привыкли к штангенциркулю. Им тоже не обязательно до 5ти сотых мерить, но намного более удобное позиционирование, сохранение результата и удобство подгонки размера — решают.
А насчет точности: ну если точность не нужна, то можно и на глаз прикинуть, а если требуется измерение, то точность точно лишней не будет :)
Впрочем аналогии между штангелем и регулярными выражениями довольно прозрачны. Конечно по всем сказанным высказываниям они проводятся, но с таким же успехом можно привести в пример колодец и спицу. Мне кажется, что это как-то не по теме топика уже.
А насчет точности: ну если точность не нужна, то можно и на глаз прикинуть, а если требуется измерение, то точность точно лишней не будет :)
Впрочем аналогии между штангелем и регулярными выражениями довольно прозрачны. Конечно по всем сказанным высказываниям они проводятся, но с таким же успехом можно привести в пример колодец и спицу. Мне кажется, что это как-то не по теме топика уже.
Очевидный вопрос — если регэкспы по сравнению с данной библиотекой предоставляют дополнительные «3 спецсимвола да пару квантификаторов», то что мешает их в нее добавить?
Ведь очевидно же, что можно сделать легко читаемый DSL для регэкспов произвольной сложности. И при этом он будет короче, чем ваш пример с комментариями, потому что большая часть этих комментариев будет не нужна.
Единственный момент — для подобных библиотек желательно строго привязывать семантику к обычным регуляркам, чтобы можно было легко переводить код туда-обратно, даже чисто механически. Т.е. пусть это будет такой многословный syntactic sugar.
Ведь очевидно же, что можно сделать легко читаемый DSL для регэкспов произвольной сложности. И при этом он будет короче, чем ваш пример с комментариями, потому что большая часть этих комментариев будет не нужна.
Единственный момент — для подобных библиотек желательно строго привязывать семантику к обычным регуляркам, чтобы можно было легко переводить код туда-обратно, даже чисто механически. Т.е. пусть это будет такой многословный syntactic sugar.
Я бы вот руки отрывал любителям писать длинные регулярки без комментариев и структурирования отступами.
Из-за таких любителей, многие и боятся регулярок.
Из-за таких любителей, многие и боятся регулярок.
Мне кажется, что регулярные выражения — более мощный аппарат, чем эта поделка.
Вообще не понимаю, какую проблему решает библиотека. Она описывает только простые выражения, которые и так читаются без проблем. Ну честно, насколько куриную память надо иметь, чтобы забыть назначение
*, +, (a|z), [a-z] и т.д.? Сложности начинаются тогда, когда возникают условные, вложенные и вообще сложные выражения, которые многие ещё и норовят записать в одну строчку.Взять, например, следующее выражение (парные скобки):
(?:[^()]|(?<b>\()|(?<-b>\)))+(?(b)(?!))или в более наглядном виде:
(?:
[^()]
|
(?<brackets> \( )
|
(?<-brackets> \) )
)+
(?(brackets)(?!))
Мне страшно подумать, как это выражение будет записано в виде «verbal expression» (если библиотека вообще будет такое когда-нибудь поддерживать).
VerEx
.OneOrMore(
VerEx
.NoncapturingGroup(
VerEx
.AnythingExcept("()")
.Or(
VerEx
.NamedGroup(
"brackets",
VerEx.Literal("(")
)
)
.Or(
VerEx
.BalancingNamedGroup(
null,
"brackets",
VerEx.Literal(")")
)
)
)
)
.Then(
VerEx
.NamedAlternation(
"brackets"
VerEx
.ZeroWidthNegativeLookahead(
VerEx.Nothing()
)
)
)
Мне кажется, что регулярные выражения — более мощный аппарат, чем эта поделка.А мне кажется, что JavaScript — более мощный аппарат, чем поделки типа jQuery
(это сарказм)
Всё равно функции преобразовывают строку в wildcard. Для первых шагов, наверное будет хорошо. Решать простые примеры тоже. Но я, не найдя, достойного описания, глянул гит, и понял, что с помощью этой библиотеки я куда дольше буду ковыряться в попытках построить какую-нибудь сложную внутристроковую конкатенацию.
К тому же, запомнить, что «Something» — это «Одно или более», а «Anything» — «Ноль или более», для меня труднее чем логические "+" и "*". А то, что Maybe это вхождение 0 или 1, лично для меня, ещё менее очевидно.
А в целом, да, тенденция «естественного общения» в любом случае тренд, как показывает практика, успешный.
К тому же, запомнить, что «Something» — это «Одно или более», а «Anything» — «Ноль или более», для меня труднее чем логические "+" и "*". А то, что Maybe это вхождение 0 или 1, лично для меня, ещё менее очевидно.
А в целом, да, тенденция «естественного общения» в любом случае тренд, как показывает практика, успешный.
> тенденция «естественного общения» в любом случае тренд
Забавно звучит. «Тенденция „естественного общения“ в любом случае тенденция» :? Ох уж это хипстерство.
По сабжу — возможно естественное обобщение и будет удобнее регэкспов, но эта конкретная реализация — нет. Описание любой мало-мальски сложной конструкции превратится в такую кашу, что можно будет мозг сломать об эти «anything» и «something».
Забавно звучит. «Тенденция „естественного общения“ в любом случае тенденция» :? Ох уж это хипстерство.
По сабжу — возможно естественное обобщение и будет удобнее регэкспов, но эта конкретная реализация — нет. Описание любой мало-мальски сложной конструкции превратится в такую кашу, что можно будет мозг сломать об эти «anything» и «something».
Чего только не придумают, лишь бы регулярные выражения не учить! :)
Я думаю был бы полезен сервис, который такое вот вербальное выражение переводил в регулярное, которое потом собственно и вставляется в рабочий код. Думаю, что и обратный сервис был бы интересен — перевод из регулярной формы в вербальную.
www.ultrapico.com/Expresso.htm посмотрите, например.
да, это вариант, но судя по шотам, там просто вариант мастера, в котором выбираешь вербальный вариант и вставляешь сразу в регулярку. А в данном случае полезная фича — это видеть всё выражение в вербальном виде.
Не вполне поняли Вашу мысль, но это gyazo.com/3a54462c736601b8f2002ea2f495bef4 не будет ответом?
Там внутри есть функция source(), которая как раз переводит VerEx в re. А вот обратно — пока нельзя, недотягивают они до re.
Думаю, что обратный сервис был бы интересен раз в 100 больше…
Для php аналог github.com/selvinortiz/flux
Осталось только сделать поддержку этих выражений в диалогах поиска и замены в популярных IDE и текстовых редакторов. Во смеху то будет!
Мы вот для иных целей создали проект imaginatio.github.io/REL/ идеи в чем то и пересекаются но только немного. Ваш проект похож так же на blog.flimflan.com/ReadableRegularExpressions.html но до него не дотягивает мне кажется.
Честно говоря, не совсем понимаю, в чём проблема читать регулярные выражения. Ну да, они могут выглядеть страшно (или очень страшно), но ведь никакой магии там нет, достаточно знать операторы (или иметь шпаргалку под рукой), несколько правил и спокойно, шаг за шагом читать. Если совсем всё плохо, то можно взять отладчик регулярных выражений (тысячи их, онлайн), разобрать его по частям, его же можно использовать для написания выражений.
Подобная вербальная запись может пригодиться для начального обучения (детей?) регулярным выражениям, в качестве транскрипции, но для большего… мне кажется — не удобно, как писать, так и читать.
Подобная вербальная запись может пригодиться для начального обучения (детей?) регулярным выражениям, в качестве транскрипции, но для большего… мне кажется — не удобно, как писать, так и читать.
Видимо, вам никогда не доводилось разбирать пятистрочную регулярку без комментариев…
Да, разумеется, магии там никакой нет, и всегда можно поэтапно разобраться — особенно если добавлять комментарии по мере разбора. Но вам не кажется, что если для понимания нескольких строчек кода кода нужно несколько минут внимательно разбирать их, то это намекает на некоторые проблемы в нотации?
Да, разумеется, магии там никакой нет, и всегда можно поэтапно разобраться — особенно если добавлять комментарии по мере разбора. Но вам не кажется, что если для понимания нескольких строчек кода кода нужно несколько минут внимательно разбирать их, то это намекает на некоторые проблемы в нотации?
Возможно данный вид выражения просто для меня непривычен, но мне кажется, что если пятистрочную регулярку записать в виде подобной транскрипции, то времени на чтение будет затрачено не меньше, чем на разбор традиционного выражения. Согласен, что проблемы есть, но их количество можно уменьшить комментированием и форматированием выражений.
А чем принципиально комментарии вида «match foo, then bar or baz» будут отличаться от приведенной записи — кроме того, что со временем регулярка и комментарий могут «разъехаться»?
Хотя на самом деле проблема с регулярками не столько в читаемости нотации, сколько в её компактности — последняя позволяет запихнуть очень много логики в очень малый объем кода, причем без каких-либо логических границ, все в кучу. В этом смысле бывает удобно включить игнорирование whitespace и попытаться выделить структуру отступами.
Еще иногда помогает побить строку регулярки на именованные части — т.е. каждый отдельный логический кусок присваивается отдельной именованной переменной, которые потом комбинируются — что-то вроде функций. Например, если парсим абсолютный URI, то можно разбивать прямо по RFC:
Только автозахват у скобок надо отключать при таком подходе. Хотя он вообще зло.
Хотя на самом деле проблема с регулярками не столько в читаемости нотации, сколько в её компактности — последняя позволяет запихнуть очень много логики в очень малый объем кода, причем без каких-либо логических границ, все в кучу. В этом смысле бывает удобно включить игнорирование whitespace и попытаться выделить структуру отступами.
Еще иногда помогает побить строку регулярки на именованные части — т.е. каждый отдельный логический кусок присваивается отдельной именованной переменной, которые потом комбинируются — что-то вроде функций. Например, если парсим абсолютный URI, то можно разбивать прямо по RFC:
$scheme = ...
$userinfo = ...
$ipv4 = ...
$ipv6 = ...
$reg_name = ...
$host = "($ipv4)|($ipv6)|($reg_name)"
$authority = "($userinfo)@($host):\d+"
$path = ...
$query = ...
$fragment = ...
$url = "($scheme)://($authority)($path)($query)($fragment)"
Только автозахват у скобок надо отключать при таком подходе. Хотя он вообще зло.
Если такую объёмную регулярку записать в одну строку, конечно её будет трудно разбирать.
С тем же успехом можно открыть jquery.min.js и сетовать на то, как сложно читать код на js.
С тем же успехом можно открыть jquery.min.js и сетовать на то, как сложно читать код на js.
Думаю такой инструмент может пригодится там, где регулярку (пусть и простую) нужно написать пользователю какого-либо приложения (далекому от regex или успевшему хорошо забыть), например для конфигурационных файлов, настроек и т.д.
Чтобы понять код в предложенной нотации, не надо иметь никаких специфических знаний вообще.
А чтобы понять голую регулярку, программисту надо стачала постичь общие принципы, синтаксис, и вообще дзен мира regexp. А на полное просветление может уйти и пару дней. После этого, конечно, все пойдет легко.
Так что, если предполагается, что ваш код будут читать программисты из других областей, такая нотация имеет смысл. Есть куча областей в мире программирования, где регулярки практически не используются в силу традиций или других причин.
А чтобы понять голую регулярку, программисту надо стачала постичь общие принципы, синтаксис, и вообще дзен мира regexp. А на полное просветление может уйти и пару дней. После этого, конечно, все пойдет легко.
Так что, если предполагается, что ваш код будут читать программисты из других областей, такая нотация имеет смысл. Есть куча областей в мире программирования, где регулярки практически не используются в силу традиций или других причин.
Только сегодня столкнулся с регулярным выражением. Обычно я их не пишу, а тупо ищу в гугле. Так вот, вставленное когда-то давно, не заработало на конкретном примере (хотя по виду все было нормально). В итоге плюнул и захардкодил, плюс сделал еще дополнительные проверки, которые там тяжело сделать (со всякими сложными «если»). Зато теперь все понятно и работает как надо. Короче, не люблю я всякую нечитабельную ересь. Каждый раз как встречаю в коде, так сразу затык.
А как будет выглядеть вербальным выражением регэксп отсюда? Цензурно?
если Вы — профессионал в использовании регулярных выражений,
А что, для того что бы использовать регулярные выражения, нужно быть профессионалом? По-моему, это уровень джуниора.
но даже они могут согласиться, что таким способом гораздо легче описать несложное (пока, прим. пер.) регулярное выражение.
Не согласен, несложное регулярное выражение написать быстрее и оно будет легче читаться в дальнейшем, потому что короче.
А что, для того что бы использовать регулярные выражения, нужно быть профессионалом? По-моему, это уровень джуниора.Что бы использовать всё что угодно — неплохо бы быть в этом профессионалом:)
Пример: посмотрев на два разных регулярных выражения выполняющих в целом одно и то же, сможет ли джуниор сказать какое из них будет работать быстрее и/или сожрет меньше памяти? Сможет ли джуниор сказать есть ли смысл переписать эту регулярку из соображений использования ресурсов? Сможет ли джуниор задать параметры входных данных, что бы регулярку можно было в разумной степени упростить? Понимает ли джуниор как именно работает внутренний механизм выполняющий регулярку?
Нарисовать регулярку джуниор должен. Но сама по себе область регулярок несколько глубже, не всем и не всегда она нужна, но профессионалы в регулярках должны знать ответы на эти и многие другие вопросы.
А что, для того что бы использовать регулярные выражения, нужно быть профессионалом? По-моему, это уровень джуниора.Угу. То-то Джеффри Фриддл томик на 500 страниц написал.
Только регулярки, только хардкор!
Слышен хохот perl-разработчиков.
«Дорогая моя Катерина Матвеевна! Во первых строках своего письма, спешу вам сообщить, что желаю видеть ваше следующее послание с красной строки, а также каждое предложение точкою завершенное».
Назовите мне, пожалуйста, одну причину, почему .startOfLine() лучше запоминается, нежели ^
P.S: кошмар какой...... Не знаю, как на счет запоминается, но читается точно лучше.
var tester = VerEx()
.startOfLine()
.then( "http" )
.maybe( "s" )
.then( "://" )
.maybe( "www." )
.anythingBut( " " )
.endOfLine();
лучше чем
https?://(www)?[^\s]*$
ORLY?
Таки ^https?://(www\.)?[^ ]+$
Крышка в начале и \s это не только пробел. А отрицания классов символов не пишутся через [^]
Но общая мысль верная, у человека в мозгу есть буфер ограниченного размера и расходовать его надо экономно, а не писать endOfLine (кстати, что это \n \A \Z \z ?)
Крышка в начале и \s это не только пробел. А отрицания классов символов не пишутся через [^]
Но общая мысль верная, у человека в мозгу есть буфер ограниченного размера и расходовать его надо экономно, а не писать endOfLine (кстати, что это \n \A \Z \z ?)
А отрицания классов символов не пишутся через [^]
Я извиняюсь, но как же они пишутся?
Меня вот тоже интересует. IDEA постоянно выдает варнинг на конструкцию вроде [^\s] но при этом [^ ] ест нормально.
Обычно для классов символов используются буквы в нижнем регистре (например,
Однако же, с ними есть одна небольшая тонкость при использовании в качестве элементов других классов. Например: выражение «не цифра и не пробел» можно записать как
\d или \s), а для инвертированных классов — в верхнем (\S, \D).Однако же, с ними есть одна небольшая тонкость при использовании в качестве элементов других классов. Например: выражение «не цифра и не пробел» можно записать как
[^\d\s], но не как [\D\S]. Второй вариант вообще не имеет смысла: поскольку цифра не является пробельным символом, а пробел — цифрой, этот класс будет работать так же, как спецсимвол «точка», то есть сопоставляться с любым символом.
del. Коммент выше все расставил на места
Упс. В перле действительно так работает.
Был неправ.
Хотя я всегда \S пишу (так же как \D \W)
Был неправ.
Хотя я всегда \S пишу (так же как \D \W)
И я, типа профессионал лезу часто. Потому что там тонны нюансов, а уж если мы полезли в Юникод…
Ну хорошо, вот я выше привёл несколько примеров для конца строки, напишите для них эквивалент словами:
\n — символ перевода строки (newline, LF, NL)
\Z Match only at end of string, or before newline at the end
\z Match only at end of string
$ что-то из \z и \Z зависит от модификатора /m
Вот 4 (на самом деле 3 разных) элемента регэкспа про конец строки. Как их записать словами?
Как записать словами?
— любой символ
— любой символ, кроме \n
Ну хорошо, вот я выше привёл несколько примеров для конца строки, напишите для них эквивалент словами:
\n — символ перевода строки (newline, LF, NL)
\Z Match only at end of string, or before newline at the end
\z Match only at end of string
$ что-то из \z и \Z зависит от модификатора /m
Вот 4 (на самом деле 3 разных) элемента регэкспа про конец строки. Как их записать словами?
Как записать словами?
— любой символ
— любой символ, кроме \n
use Expresso Luke. :)
Для детей сойдёт.
В текущем виде библиотека слабоприменима, генерит много шума и нецелесообразна к использованию (на работе уже пообсуждали).
Вот пример простого регулярного выражения, который попытались написать при помощи C# версии. Много чего нету (группировок даже нету, не говоря о бэктрекинге), результат — уг
https://gist.github.com/centur/6163774 С# Verbal Regex
Вот пример простого регулярного выражения, который попытались написать при помощи C# версии. Много чего нету (группировок даже нету, не говоря о бэктрекинге), результат — уг
https://gist.github.com/centur/6163774 С# Verbal Regex
Для изучения смысла регулярок — пойдёт. Выучить синтаксис обычных регулярок не сложно, и шпаргалить там нечего, сложно синтезировать (и в некоторых случаях разобрать) логику. Изучив однажды регулярки, мозг и сам будет «проговаривать» их мысленно, на любом удобном вербальном языке. Сложные для разбора выражения на такой библиотеке будут все равно не менее адскими, чем на языке регулярок.
Если хочется читаемого формата, то есть ABNF (BNF), это общепринятый и хорошо читаемый формат описания больших синтаксических структур, без которого уже около 50 лет не обходится ни один серьезный протокол, формат данных, язык программирования или спецификация, проходящая через Internet Engineering Task Force (IETF), W3C и IEEE. Он компилируется в регулярные выражения и в парсеры строковыми операциями для кучи языков (Java, C++, C#, JavaScript и т.д.).
Да, отсутствие в регэкспах чего-то типа констант/переменных/нетерминальных символов убивает, особенно при необходимости читать чужой килобайтный копипаст…
Процитирую Никиту Попова (да, это валидатор емейла согласно RFC 5322):
nikic.github.io/2012/06/15/The-true-power-of-regular-expressions.html
Мне кажется, что это не шибко сложнее BNF, и вам всего должно тут хватить.
/
(?(DEFINE)
(?<addr_spec> (?&local_part) @ (?&domain) )
(?<local_part> (?&dot_atom) | (?"ed_string) | (?&obs_local_part) )
(?<domain> (?&dot_atom) | (?&domain_literal) | (?&obs_domain) )
(?<domain_literal> (?&CFWS)? \[ (?: (?&FWS)? (?&dtext) )* (?&FWS)? \] (?&CFWS)? )
(?<dtext> [\x21-\x5a] | [\x5e-\x7e] | (?&obs_dtext) )
(?<quoted_pair> \\ (?: (?&VCHAR) | (?&WSP) ) | (?&obs_qp) )
(?<dot_atom> (?&CFWS)? (?&dot_atom_text) (?&CFWS)? )
(?<dot_atom_text> (?&atext) (?: \. (?&atext) )* )
(?<atext> [a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+ )
(?<atom> (?&CFWS)? (?&atext) (?&CFWS)? )
(?<word> (?&atom) | (?"ed_string) )
(?<quoted_string> (?&CFWS)? " (?: (?&FWS)? (?&qcontent) )* (?&FWS)? " (?&CFWS)? )
(?<qcontent> (?&qtext) | (?"ed_pair) )
(?<qtext> \x21 | [\x23-\x5b] | [\x5d-\x7e] | (?&obs_qtext) )
# comments and whitespace
(?<FWS> (?: (?&WSP)* \r\n )? (?&WSP)+ | (?&obs_FWS) )
(?<CFWS> (?: (?&FWS)? (?&comment) )+ (?&FWS)? | (?&FWS) )
(?<comment> \( (?: (?&FWS)? (?&ccontent) )* (?&FWS)? \) )
(?<ccontent> (?&ctext) | (?"ed_pair) | (?&comment) )
(?<ctext> [\x21-\x27] | [\x2a-\x5b] | [\x5d-\x7e] | (?&obs_ctext) )
# obsolete tokens
(?<obs_domain> (?&atom) (?: \. (?&atom) )* )
(?<obs_local_part> (?&word) (?: \. (?&word) )* )
(?<obs_dtext> (?&obs_NO_WS_CTL) | (?"ed_pair) )
(?<obs_qp> \\ (?: \x00 | (?&obs_NO_WS_CTL) | \n | \r ) )
(?<obs_FWS> (?&WSP)+ (?: \r\n (?&WSP)+ )* )
(?<obs_ctext> (?&obs_NO_WS_CTL) )
(?<obs_qtext> (?&obs_NO_WS_CTL) )
(?<obs_NO_WS_CTL> [\x01-\x08] | \x0b | \x0c | [\x0e-\x1f] | \x7f )
# character class definitions
(?<VCHAR> [\x21-\x7E] )
(?<WSP> [ \t] )
)
^(?&addr_spec)$
/x
nikic.github.io/2012/06/15/The-true-power-of-regular-expressions.html
Мне кажется, что это не шибко сложнее BNF, и вам всего должно тут хватить.
Странно что никто не вспомнил тут про SQL — ну те же «вербальные выражения» только вот че то как то не очень оно порог вхождения меняет. Все равно очередной «птичий язык», нужно запоминать что вместо «крышки» .startOfLine() (не begin, не new) различные точки, экранирование. Помнить как записать «любая цифра» или alphanumeric. Как строить сложные «это или это, но не вот это если после того».
Да читабельней, но длинней.
Так что мое мнение для использования не нужно, но для обучения принципам построения выражений как подготовка к регуляркам, может пригодиться так же как Бейсик или Паскаль для подготовки с всяким Си и Джавам.
Да читабельней, но длинней.
Так что мое мнение для использования не нужно, но для обучения принципам построения выражений как подготовка к регуляркам, может пригодиться так же как Бейсик или Паскаль для подготовки с всяким Си и Джавам.
Для регэкспов есть множество отличных наглядных конструкторов. Пример — www.debuggex.com/. Используйте и не гребите мозг обёртками…
Все здорово, мне нравится.
Единственная проблема пока, которую я вижу — это вынос подобных выражений в конфигурационные файлы. Если с регксами все было просто, то тут еще нужен будет конвертор, который из текста будет преобразовать вербальный экспрешен в код.
Единственная проблема пока, которую я вижу — это вынос подобных выражений в конфигурационные файлы. Если с регксами все было просто, то тут еще нужен будет конвертор, который из текста будет преобразовать вербальный экспрешен в код.
Зачем декларативный стиль регулярок приводить к менее декларативным функциям (указывается точный порядок вызова).
Если так хочется дать символам названия — то и давайте.
"~startOfLine~
~mayBe space~
…
"
Можно заменять символы частично (к примеру оставлять некоторые конструкции, типа [A-z0-9]), а сложные куски делать вхождениями
tcpIP = «http{or}ftp{or}....»
Регулярка, что-нибудь типа
"~startOfLine~
~~tcpIP~~
...[A-z0-9_/]+"
В общем основная мысль моего комментария, в том, что преимущество регулярок в целостной декларативности, которая позволяет очень многое и терять ее смысла нет.
Если так хочется дать символам названия — то и давайте.
"~startOfLine~
~mayBe space~
…
"
Можно заменять символы частично (к примеру оставлять некоторые конструкции, типа [A-z0-9]), а сложные куски делать вхождениями
tcpIP = «http{or}ftp{or}....»
Регулярка, что-нибудь типа
"~startOfLine~
~~tcpIP~~
...[A-z0-9_/]+"
В общем основная мысль моего комментария, в том, что преимущество регулярок в целостной декларативности, которая позволяет очень многое и терять ее смысла нет.
Ok, Glass,
var tester = VerEx()
.startOfLine()
.then( «http» )
.maybe( «s» )
.then( "://" )
.maybe( «www.» )
.anythingBut( " " )
.endOfLine();
Это же очевидно.
var tester = VerEx()
.startOfLine()
.then( «http» )
.maybe( «s» )
.then( "://" )
.maybe( «www.» )
.anythingBut( " " )
.endOfLine();
Это же очевидно.
Всем, кто ругает высокоуровневый инструмент за то, что он менее мощный и универсальный, чем низкоуровневый, предлагаю бросить JS, PHP или на чём вы там пишете, и писать всё исключительно на ассемблере.
Задача инструментов высокого уровня — уменьшать количество кода, а не увеличивать его.
Это неверно. Задача — оперировать абстракциями более высокого уровня. Количества кода при этом может быть и больше.
Вот, например, программа на низкоуровневом C, попробуйте угадать её предназначение и понять, как она работает:
Текст программы занимает всего 1433 байта, все аналоги, написанные с помощью более высокоуровневых инструментов (подходов), на порядки больше, но зато и понятнее, и поддерживать их проще, значит задачу высокоуровневые инструменты выполнили.
Вот, например, программа на низкоуровневом C, попробуйте угадать её предназначение и понять, как она работает:
#define W while
int M=136,S=128,I=8e3,C=799,Q,O,K,N;
char L,*P,
w[]={0,1,1,-1,3,3,5,9},
o[]={-16,-15,-17,0,1,16,0,1,16,15,17,0,14,18,31,33,0,7,-1,6,11,8,3,6,6,4,5,7,3,5,4,6},
b[129],
n[]=".?+knbrq?*?KNBRQ",
c[9];
D(k,q,l,e,E,z,n)
int k,q,l,e,E,z,n;
{
int j,r,m,v,d,h,i,F,G,s;
char t,p,u,x,y,X,Y,H,B;
q--;
d=X=Y=0;
W(d++<n||
z==8&K==I&&(N<1e6&d<98||
(K=X,L=Y&~M,d=2)))
{x=B=X;
h=Y&S;
m=d>1?-I:e;
N++;
do{u=b[x];
if(u&k)
{r=p=u&7;
j=o[p+16];
W(r=p>2&r<0?-r:-o[++j])
{A:
y=x;F=G=S;
do{
H=y=h?Y^h:y+r;
if(y&M)break;
m=E-S&&b[E]&&y-E<2&E-y<2?I:m;
if(p<3&y==E)H^=16;
t=b[H];if(t&k|p<3&!(y-x&7)-!t)break;
i=99*w[t&7];
m=i<0?I:m;
if(m>=l)goto C;
if(s=d-(y!=z))
{v=p<6?b[x+8]-b[y+8]:0;
b[G]=b[H]=b[x]=0;b[y]=u|32;
if(!(G&M))b[F]=k+6,v+=30;
if(p<3)
{v-=9*((x-2&M||b[x-2]-u)+
(x+2&M||b[x+2]-u)-1);
if(y+r+1&S)b[y]|=7,i+=C;
}
v=-D(24-k,-l,m>q?-m:-q,-e-v-i,F,y,s);
if(K-I)
{if(v+I&&x==K&y==L&z==8)
{Q=-e-i;O=F;
if(b[y]-u&7&&P-c>5)b[y]-=c[4]&3;
return l;
}v=m;
}
b[G]=k+6;b[F]=b[y]=0;b[x]=u;b[H]=t;
if(v>m)
m=v,X=x,Y=y|S&F;
if(h){h=0;goto A;}
}
if(x+r-y|u&32|
p>2&(p-3|j-7||
b[G=x+3^r>>1&7]-k-6
||b[G^1]|b[G^2])
)t+=p<5;
else F=y;
}W(!t);
}}}W((x=x+9&~M)-B);
C:if(m>I-M|m<M-I)d=98;
m=m+I?m:-D(24-k,-I,I,0,S,S,1);
}
return m+=m<e;
}
main()
{
int k=8;
K=8;W(K--)
{b[K]=(b[K+112]=o[K+24]+8)+8;b[K+16]=18;b[K+96]=9;
L=8;W(L--)b[16*L+K+8]=(K-4)*(K-4)+(L-3.5)*(L-3.5);
}
W(1)
{N=-1;W(++N<121)
printf(" %c",N&8&&(N+=7)?10:n[b[N]&15]);
P=c;W((*P++=getchar())>10);
K=I;
if(*c-10)K=*c-16*c[1]+C,L=c[2]-16*c[3]+C;
k^=D(k,-I,I,Q,O,8,2)-I?0:24;
}
}
Ответ
Это один из самых маленьких шахматных движков в мире, значащие символы занимают всего 1433 байта.
Текст программы занимает всего 1433 байта, все аналоги, написанные с помощью более высокоуровневых инструментов (подходов), на порядки больше, но зато и понятнее, и поддерживать их проще, значит задачу высокоуровневые инструменты выполнили.
Причем тут уровни языка и названия переменных?
Высокоуровневые языки дают возможность уменьшать количества кода путем ввода дополнительных конструкций: переменных, функций, операторов, условных конструкций, констант, lambda-выражений, макросов и т.д. Все это позволяет автоматизировать процесс написания кода, т.е. интерпретатор или компилятор пишет код за вас.
Точно так же можно и в языках любого уровня можно давать короткие названия всем объектам, а пример который вы привели примитивный и не на самом низкоуровневом языке. Попробуйте написать что-либо с выделением памяти, работой с сетью, 3D и т.д.
a=1;b=function©{return {d:c+a};};alert(b(1).d);
Высокоуровневые языки дают возможность уменьшать количества кода путем ввода дополнительных конструкций: переменных, функций, операторов, условных конструкций, констант, lambda-выражений, макросов и т.д. Все это позволяет автоматизировать процесс написания кода, т.е. интерпретатор или компилятор пишет код за вас.
Точно так же можно и в языках любого уровня можно давать короткие названия всем объектам, а пример который вы привели примитивный и не на самом низкоуровневом языке. Попробуйте написать что-либо с выделением памяти, работой с сетью, 3D и т.д.
a=1;b=function©{return {d:c+a};};alert(b(1).d);
Вас не понять.
Сначала вы пишете, что
И если в программе выше вы увидели только короткие переменные, то как говорится, у меня для вас плохие новости.
Утверждаете, что высокоуровневые инструменты исключительно для сокращения объёма кода? Возьмите любой такой инструмент с замыканиями, итераторами, монадами и чем угодно, и попробуйте написать аналогичную шахматную программу того же размера.
Другие авторы, когда пишут код осознанно выделяют новые уровни абстракции в ущерб количеству кода, и получается у них, например 2500 строк, что на 2 порядка больше. И это оправдано, ибо мало кода — это хорошо только для своего рода произведения искусства, как пример выше. На практике же важна скорость написания, читабельность и стоимость поддержки, а не количество строк.
Сначала вы пишете, что
.startOfLine() хуже, чем символ ^, потому что задача «уменьшить количество кода», а потом вам однобуквенные переменные не нравятся.И если в программе выше вы увидели только короткие переменные, то как говорится, у меня для вас плохие новости.
Утверждаете, что высокоуровневые инструменты исключительно для сокращения объёма кода? Возьмите любой такой инструмент с замыканиями, итераторами, монадами и чем угодно, и попробуйте написать аналогичную шахматную программу того же размера.
Другие авторы, когда пишут код осознанно выделяют новые уровни абстракции в ущерб количеству кода, и получается у них, например 2500 строк, что на 2 порядка больше. И это оправдано, ибо мало кода — это хорошо только для своего рода произведения искусства, как пример выше. На практике же важна скорость написания, читабельность и стоимость поддержки, а не количество строк.
на час улетел в ваш пример
это потрясающе
особенно первая строчка с комментарием «castling-on-Pawn-check bug fixed»
это потрясающе
особенно первая строчка с комментарием «castling-on-Pawn-check bug fixed»
Вы пишите на Regexp столько же кода как и на перечисленных языках (или все таки одну строчку)?
Идея интересная, но это должны быть не вызовы функций, а макросы, которые ещё до исполнения развернутся в обычное регулярное выражение.
а) В большинстве языков таких макросов нет.
б) Зачем? Компиляция и выполнение самого регулярного выражения явно займёт значительно больше времени, чем вызов этих функций и получение строки-регулярки.
б) Зачем? Компиляция и выполнение самого регулярного выражения явно займёт значительно больше времени, чем вызов этих функций и получение строки-регулярки.
Более интересна идея, когда вызовы функций дают сразу скомпилированную регулярку, минуя стадию текста.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хватит писать регулярные выражения. Используйте вербальные выражения