Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.
Появилась потребность выучить Text Manipulation Language. Начал выбирать и остановился на PERL, но коллега подсказал, что лучше будет Python. Посоветуйте, что действительно будет лучше для моих целей?
-Перл НЕТ, что угодно, только не перл.
Что ж так все перла боятся. Я, например, если выбор между шелом и перлом, всегда выбираю перл ;)
Python — www.nltk.org або Java — alias-i.com/lingpipe
Если посерьёзнее, то лучше и понятнее будет Python/Ruby.
Питон.
И R для того, чтобы логи анализировать прямо из командной строки вдоль и поперек(если конечно в память влазят, если не влазят, то придется помучиться).
Python вообще хороший язык и библиотек для работы с текстом должно быть много. Я, конечно, не шибко спец в нем, но он мне по душе!
Судя по каментам, чаша весов склоняется в сторону питона. Что ж тогда и выбор назревает. Всем спасибо!
мне лично очень по душе подход питона, где для каждой фичи создатели языка стараются выбрать один канонический вариант. я далеко не всегда согласен с их выбором, но ради общей чистоты готов с этим мириться. в противоположность этому, в перле фичи нагромождаются друг на друга, и для написания чистого читабельного кода требуются определенные усилия (имно). впрочем, еще лет
regexp уже есть везде , так что ... выбор таки более релегиозный :)
Но я где-то слышал что Перл это язый для написания кода но не для читания. Когда я еще работал с ним (10 лет назад), то почти не видел «красивого кода», все было написано так что б это работало и забыть .... и у меня остался такой «осадок» о нем.
Python будет лучше, перл клевый, а к ос-зависимым лучше не привязываться :)
Мы юзаем Perl для анализа/преобразования больших логов и нет-листов, генерируемых разл. тулзами. Вроде, хватает.
Авторы вышеупомянутой книги советуют Perl как наиболее лаконичный и удобный для подобных задач. Но Python выглядит более перспективный. Вот и дилема.
Если надо для винды, то почему бы не использовать Power Shell?.
А это интересно. Как раз соответсвует бизнес-логике (у нас .NET). Нужно узнать подробней.
помогает )))))))
Жалкое еретическое подобие шелла!! Тормозит и глючит!
Почему просто не попробовать решить одну и туже простенькую задачу использовав по очереди оба языка и выбрать тот, который больше понравится? Литературу, примеры и сообществ должно быть достаточно.
“If you want to know if Perl is better than language X, learn them both and try to see which one you use most often. That’s the one that’s best for you. In the end, you’ll understand Perl better because of your study of language X, and vice versa, so it will be time well spent.”
Я за питон, так как знания потом смогут зареюзаться намного шире чем в случае с перлом
Всяк кулик свое болото будет хвалить. Надо самому попробовать оба в маленькой задаче, почувстовать их на вкус, так сказать. Для кого-то perl — «горбатый язык», а кого-то он восхищает своей идеоматичностью. А про питона вообще промолчу. =)
Если ваша цель — выучить Text Manipulation Language то вы строго говоря можете учить любой. Какой бы вы ни выучили — цель будет достигнута.
Если же ваша цель, решать какой-то круг задач с помощью этого языка, то увы, телепаты в отпуске и не зная какие задачи вы собираетесь решать невозможно подсказать какой язык вам лучше подходит.
В-третиьх, при прочих равных, при условии абсолютной незнакомости с каждым из языков, Perl будет более эффективным решением для задач подразумевающих манипуляции с текстом.
Ну.... Это не главное. Наверное больше для анализа логов... Я не знаю насколько для этого нужны регулярные выражения. Да и вообще для общих админских задач.
если для админских, то Tcl. он очень быстрый, простой (годится даже для не программера), крохотный и работает всюду.
Для сбора простой и сложной статистики и прочего манипулирования текстом хватит регулярных выражений с головой.Ну.... Это не главное. Наверное больше для анализа логов... Я не знаю насколько для этого нужны регулярные выражения. Да и вообще для общих админских задач.
Если будет необходимо генерировать графические файлы (а ля MRTG, который написан в основном на перле), то Perl не самый удачный выбор.
И так далее.
Регулярные выражения из Перл частично позаимствовал ORACLE 11g так что знаком.
Доводилось парсить регулярками, особых сложностей не заметил.
HTML не парсится контекстно-свободной грамматикой.
А помоему как раз таки правильный хтмл и парсится свободноконтекстной граматикой, а вот распарсит ли regexp любую свободноконтекстную граматику, вопрос посложнее, безотносительно ответа на который xpath будет в 10 раз удобнее для таких задач.
распарсит ли regexp любую свободноконтекстную граматику, вопрос посложнее
контекстно-свободный язык не парсится регулярными выражениями. ищем в интернетах слова pumping lemma и учим матчасть.
Учимся читать и ищем где я утверждал обратное.
Контекстно-свободную не распарсить регекспами как таковыми, но дело в том, что в перле том же регекспы как бы не совсем простые регекспы, с их рекурсией и бектрекингом. Так что можно попытаться. Другое дело, что HTML — не XML, допускает кучу кривизны, которая часто встречается в реале. Именно это и не позволяет парсить его контекстно свободной грамматикой, и XPath тут тоже будет бессилен, т.к. это не XML.
Непреодолимой кривизны не бывает если твой хтмл способен распарситься в дом в браузере.
Но кривизна преодолевается явно не регекспами, и уверен, что даже если там что-то yacc подобное и есть, то с костылями. Как, кстати и perl, который не имеет грамматики в BNF.
Дык я ж агитирую за xpath а не регекспы(если не нужна суперпроизводительность конечно), а кривость хтмл-а лечится соответствующими тулзами которые его преобразуют в xhtml.
полечить тулзами — вариант, тогда те же вопросы к лечилке :)
А какая программисту разница как лечилка решает эти проблемы?
А лечилки делают не программисты, они даны свыше как откровение :)
Может сразу посоветуешь ему для парсинга логов подучить устройство линукс ядра и архитектуру процов?
Нед. Для парсинга советую подучить парсинг, и то только для кейса, где регекспы не катят, разве не логично?
Отлично, а то я глядя на твои предыдущие посты уж начал беспокоиться.
You can’t parse [X]HTML with regex. Because HTML can’t be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. As I have answered in HTML-and-regex questions here so many times before, the use of regex will not allow you to consume HTML. Regular expressions are a tool that is insufficiently sophisticated to understand the constructs employed by HTML. HTML is not a regular language and hence cannot be parsed by regular expressions. Regex queries are not equipped to break down HTML into its meaningful parts. so many times but it is not getting to me. Even enhanced irregular regular expressions as used by Perl are not up to the task of parsing HTML. You will never make me crack. HTML is a language of sufficient complexity that it cannot be parsed by regular expressions. Even Jon Skeet cannot parse HTML using regular expressions. Every time you attempt to parse HTML with regular expressions, the unholy child weeps the blood of virgins, and Russian hackers pwn your webapp. Parsing HTML with regex summons tainted souls into the realm of the living. HTML and regex go together like love, marriage, and ritual infanticide. The <center> cannot hold it is too late. The force of regex and HTML together in the same conceptual space will destroy your mind like so much watery putty. If you parse HTML with regex you are giving in to Them and their blasphemous ways which doom us all to inhuman toil for the One whose Name cannot be expressed in the Basic Multilingual Plane, he comes. HTML-plus-regexp will liquify the nerves of the sentient whilst you observe, your psyche withering in the onslaught of horror. Rege̿̔̉x-based HTML parsers are the cancer that is killing StackOverflow it is too late it is too late we cannot be saved the trangession of a chi͡ld ensures regex will consume all living tissue (except for HTML which it cannot, as previously prophesied) dear lord help us how can anyone survive this scourge using regex to parse HTML has doomed humanity to an eternity of dread torture and security holes using regex as a tool to process HTML establishes a breach between this world and the dread realm of c͒ͪo͛ͫrrupt entities (like SGML entities, but more corrupt) a mere glimpse of the world of regex parsers for HTML will instantly transport a programmer’s consciousness into a world of ceaseless screaming, he comes, the pestilent slithy regex-infection will devour your HTML parser, application and existence for all time like Visual Basic only worse he comes he comes do not fight he com̡e̶s, ̕h̵is un̨ho͞ly radiańcé destro҉ying all enli̍̈́̂̈́ghtenment, HTML tags lea͠ki̧n͘g fr̶ǫm ̡yo͟ur eye͢s̸ ̛l̕ik͏e liquid pain, the song of re̸gular expression parsing will extinguish the voices of mortal man from the sphere I can see it can you see ̲͚̖͔̙î̩́t̲͎̩̱͔́̋̀ it is beautiful the final snuffing of the lies of Man ALL IS LOŚ͖̩͇̗̪̏̈́T ALL IS LOST the pon̷y he comes he c̶̮omes he comes the ichor permeates all MY FACE MY FACE ᵒh god no NO NOO̼OO NΘ stop the an*̶͑̾̾̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨe̠̅s ͎a̧͈͖r̽̾̈́͒͑e not rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ
regexp ?
Grez
Michael P
Yaroslav Pogrebnyak
Pavlo Mashchak
Valeriy Zamaraiev
odonacer
Антон Товстоноженко
Sergiy Matusevych
Ramsess in UA
Michael P
Denis Muratov
Mike Gorchak
Eugene Stogniy
Bogdan Shyiak
Yaroslav Korshak
reality_hacker
Олександр Петров
Andrii Mishkovskyi
henry flower
anonymous
Valeriy Zamaraiev
reality_hacker
Sergiy Matusevych
Mykhailo Troianovskyi
Mike Gorchak
49 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів