Ruby python или perl

perl & ruby & python

Подскажите, пожалуйста,
в чём их различие, в чём сходство!

что для чего больше подходит.

Re: perl & ruby & python

perl: лучше всего подходит для простых «однострочных» програмок, обрабатывающих (текстовый)поток|файл. Если программа чуть побольше — лучше не использовать.

python: хорош почти везде, но однострочник на нем практически невозможен.

ruby: если тебе не нравится синтаксис питона или очень нравиться perl и програмка не тривиальна.

Скорость у всех не очень, но есть оптимизированые библиотеки и «обходные» пути. Например, psyco (говорят) может ускорить python-код на порядки.

Re: Re: perl & ruby & python

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

Re: Re: perl & ruby & python

> perl: лучше всего подходит для простых «однострочных» програмок, обрабатывающих (текстовый)поток|файл. Если программа чуть побольше — лучше не использовать.

чуть побольше? это сколько? 10 000 — 15 000 строк кода это чуть побольше или не чуть? работает на ура.

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

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

Автору: сходи на www.cpan.org посмотри сколько там инструментов предлагается для решения самых разнообразных задач.

Re: Re: Re: perl & ruby & python

забыл уточнить, что www.cpan.org — это сайт с модулями для perl.

Re: Re: Re: perl & ruby & python

> + в перл, imho, более приятно организовано расширение возможностей языка через подключение модулей.

А в питоне нет модулей или их трудно подключить? А здесь, что: http://www.python.org/pypi?:action=index

PS: Против перла я никогда не был, но пока пользуюсь питоном, потому как синтаксис мне его нравится. А из вприведенной фразы следует, что подключение модулей в питоне если есть, то полная «жопа», ИМХО, это не так.

Re: Re: Re: perl & ruby & python

> Добавлю. Если нужна обработка текста регэкспами — то перл однозначно (он вырос из регэкспов, они в нем органическая часть языка, а в рабби и, особенно, пистоне регэкспы пришлепнуты сбоку).

Поясню: то, что автор комментария называет «пришлепнуты сбоку» означает — реализованы в виде библиотек (Про Ruby не скажу, я его совсем не знаю, а в Python именно так).

В результате, в простых случаях в Perl код получается проще и короче. В Python всё несколько сложнее, там результат поиска не строка, а более сложный объект, который кроме найденной строки содержит дополнительную информацию. В итоге в Python код обычно получается длиннее, но зато появляются дополнительные возможности. Например, в Perl нелегко найти позицию найденной строки в исходной, а в Python эта информация содержится в объекте-результате поиска.

Ещё один плюс библиотеки: её легче развивать и дополнять, чем изменять синтаксис (в Perl регулярные выражения — часть синтаксиса).

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

> Если обработка текста не нужна — то языки практически равнозначны, пистон чуть поприятнее.

В задачах обработки текста Python тоже ничем не уступает.

Re: Re: Re: Re: perl & ruby & python

> называет «пришлепнуты сбоку» означает — реализованы в виде библиотек

С откровенно неудачным и неудобным (зато «привычным и единообразным») интерфейсом.

> в простых случаях в Perl код получается проще и короче.

В сложных тоже. В самых сложных для _любого_ языка придется использовать lex&yacc.

> Например, в Perl нелегко найти позицию найденной строки в исходной,

Вот уж чего совсем не надо делать.

> Ещё один плюс библиотеки: её легче развивать и дополнять,

Но трудно и неудобно использовать.

> В Python, кроме того, есть функция findall

> В задачах обработки текста Python тоже ничем не уступает.

regexp

> > называет «пришлепнуты сбоку» означает — реализованы в виде библиотек

> С откровенно неудачным и неудобным (зато «привычным и единообразным») интерфейсом.

В чём неудачность и неудобство? Желательно с примерами.

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

> > в простых случаях в Perl код получается проще и короче.

Короче в любом случае — наверное, да. Но проще, означает ещё и легче для написания и прочтения. А для этого часто легче сделать сложное действие в несколько этапов: сначало получить результат поиска, потом проделать с ним какие-то действия.

> В самых сложных для _любого_ языка придется использовать lex&yacc.

Существует реализация (правда, не совсем полная) на чистом Питоне. Занятная вещица. 🙂

> > Например, в Perl нелегко найти позицию найденной строки в исходной,

>Вот уж чего совсем не надо делать.

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

> > Ещё один плюс библиотеки: её легче развивать и дополнять,

> Но трудно и неудобно использовать.

То же, что по первому пункту.

> > В Python, кроме того, есть функция findall

> /. /g в списковом контексте.

Мой промах, упустил. Спасибо. Замечание снимается.

> > В задачах обработки текста Python тоже ничем не уступает.

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

Re: regexp

> В чём неудачность и неудобство? Желательно с примерами.

Код намного длиннее и мутнее. Не очень удобно писать многострочные регэспы.

Очень буду рад, если вы найдете _мой_ промах, но напишите на питоне аналог s/%%(.*?)%%/$1/gee;

> Возможность откомпилировать регексп и потом использовать откомпилированный, это неудачно или неудобно?

Неудачно, потому что появляется дополнительная переменная и что же она делает неочевидно: приходится постоянно возвращаться к ее определению.

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

> Существует реализация (правда, не совсем полная) на чистом Питоне.

Не знаю как _на_ perl, а _для_ perl подобные вещи тоже есть.

> «Нет, значит не надо» или «не надо мне, значит не надо другим»? Извините, не аргумент.

Ну а для чего это может быть нужно? Выделить подстроку — так это значение уже есть. Изменить переменную — гнилая затея, в языках высокого уровня все переменные должны быть write-once.

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

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

Про проще и короче

>>С неудачным и неудобным (зато "привычным и единообразным") интерфейсом. >В чём неудачность и неудобство? Желательно с примерами. Всегда, кроме простейших случаев будет так: на perl: if(/blablabla/) < do something with $1 $2 $3; >else < do something else; >на python: try: a,b,c,d=re.match(line) do something with a b c d except: do something else или mo=re.match(line) if mo: do something with mo else: do something else выглядит действительно менее удобно - особенно второй вариант. Но это скорее вопрос привычки. А длинна - практически такая же. > > в простых случаях в Perl код получается проще и короче. >В сложных тоже. В сложных - нет. Перл _длиннее_ и _сложнее_ в многочисленных -> <> $ @ на достаточно сложных обьектах. При этом "теряется" начальное преимущество - многочисленные импорты питона уравновешиваются use-ами. Остается только выигрыш на "укороченых" операторах - m//, s//, и "коротких" управляющих операторах типа "do this until condition". То есть perl короче - на уровне процентов. Зато читаемость хуже. Что кому более важно?

Кстати, о продвинутых языках

>В самых сложных для _любого_ языка придется использовать lex&yacc.

В Haskell «import Parsec» — и не нужен lex+yacc 🙂

Re: Re: regexp

А давайте сначала определим:

2. как будем реагировать на ошибки.

>остальные возможности имеют значение только если возможности по обработке текста одинаковы.

Это только если обработка сводится _в_основном_ к обработке текста.

Re: Re: Re: regexp

> 1. что сие должно делать.

> 2. как будем реагировать на ошибки.

Какие ошибки? Опишите ситуацию.

> Это только если обработка сводится _в_основном_ к обработке текста.

Ну так мы вроде _только_ про обработку текста и говорили.

Re: Кстати, о продвинутых языках

> В Haskell «import Parsec» — и не нужен lex+yacc 🙂

Нужет хороший (ну не очень плохой) компилятор, а его нет. 🙂

Re: Re: regexp

> Очень буду рад, если вы найдете _мой_ промах, но напишите на питоне аналог s/%%(.*?)%%/$1/gee;

Я уже подзабыл опции поиска в Перле и совсем не понял, что означают две буквы ‘e’, поэтому могу ошибиться. Если я правильно понял, то на Питоне будет так:

где line содержит исходную строку. При этом line не изменяется — отсутствует побочный эффект. Цитирую: «Изменить переменную — гнилая затея, в языках высокого уровня все переменные должны быть write-once.» 🙂

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

Для составления регекспов для более сложных случаев, нужно затратить приличное время, чтобы учесть все тонкости. Даже выражение для выделения действительного числа может оказаться весьма непростым. Я думаю, что всё же проще догадаться, для чего служат переменные url_pattern, file_name_pattern, mail_address_pattern, чем разбираться в достаточно сложных регекспах, из которых они были получены. Ведь вы же определяете и вызываете функции, а не копируете каждый раз куски кода? А если в очередной версии программы шаблон нужно будет изменить? К тому же, насколько я понимаю, использование предварительно откомпилированных выражений улучшает производительность.

Встречный вопрос на засыпку: как в одной программе в одних случаях применять локаль при поиске/замене, а в других нет?

> Ну а для чего это может быть нужно? Выделить подстроку — так это значение уже есть.

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

Кстати, в Перле это тоже возможно, но IMHO менее удобно.

Источник