Добрый день!

В данный момент потихоньку разбираюсь с Perl. Для себя самого — писать скрипты, автоматизирующие рутинную работу: архивирование файлов, загрузка новостей с сайтов, проверка почты, анализ лог-файлов и т.д.
Ruby и Python не знаю совсем. Вопрос такой — есть ли у этих языков преимущества для решения обозначенных выше задач? Стоит ли тратить время на их изучение(с сугубо практической точки зрения) или они по возможностям аналогичны Perl?
В каких задачах проявляются преимущества одного языка, а когда другого?

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

Спасибо

Здравствуйте, DemAS, Вы писали:

DAS> Добрый день!

DAS> В данный момент потихоньку разбираюсь с Perl. Для себя самого — писать скрипты, автоматизирующие рутинную работу: архивирование файлов, загрузка новостей с сайтов, проверка почты, анализ лог-файлов и т.д.
DAS> Ruby и Python не знаю совсем. Вопрос такой — есть ли у этих языков преимущества для решения обозначенных выше задач? Стоит ли тратить время на их изучение(с сугубо практической точки зрения) или они по возможностям аналогичны Perl?
DAS> В каких задачах проявляются преимущества одного языка, а когда другого?

DAS> Прошу прощения, если дискуссия приведет к тому, что вопрос окажется в Священных Войнах.

DAS> Спасибо

про Ruby сказать ничего не могу, про Python, в книге Лутца приводится изречение из телеконференции на эту тему, где обыгрывается разговор мастера йоды с люком , ключевая фраза: силу Python ты поймешь, попытавшись прочитать свой код через полгода, намекая на то, что код Perl будет очень трудно читаемым.
На мой взгляд править код Python не удобно, вставить пару условий и циклов в середину, , это должно видно заставить лучше относится к фазе проектирования.
Из архитектурных преимуществ Python над Perl, то что он с самого начала был ООП(поддерживает множественное наследование даже ), а к Perl оно было потом прикручено, на взгляд многих, так же как и в PHP4, кривовато, что не мешает последним быть более популярными, видно из-за знака $

Здравствуйте, DemAS, Вы писали:
DAS> Ruby и Python не знаю совсем. Вопрос такой — есть ли у этих языков преимущества для решения обозначенных выше задач? Стоит ли тратить время на их изучение(с сугубо практической точки зрения) или они по возможностям аналогичны Perl?
Я с успехом применяю именно Руби в повседневных (и, причем, аналогичных) случаях, и просто поражен чистотой и прозрачностью языка.

Здравствуйте, fNt, Вы писали:

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

Могу сказать то же самое о Python — язык потрясающе удобный и элегантный. Единственное "но" — идея форматирования кода отступами, конечно, красива, но порой причиняет некоторые неудобства. А так вообще язык очень хорош: с одной стороны достаточно функционален, а с другой — очень прост и понятен даже начинающему.

Здравствуйте, cadet354, Вы писали:

DAS>> В каких задачах проявляются преимущества одного языка, а когда другого?
DAS>> Прошу прощения, если дискуссия приведет к тому, что вопрос окажется в Священных Войнах.
Не хотелось бы — я на них не подписан.

C>про Ruby сказать ничего не могу, про Python, в книге Лутца приводится изречение из телеконференции на эту тему, где обыгрывается разговор мастера йоды с люком , ключевая фраза: силу Python ты поймешь, попытавшись прочитать свой код через полгода, намекая на то, что код Perl будет очень трудно читаемым.
Уже сказали одному Обероиду, что никто не заставляет писать неразборчиво. На Perl можно писать читаемый код. На Python можно писать нечитаемый код. По сравнению с Пайтоном в этом смысле у Перла есть один плюсик: в нужный момент можно воспользоваться гибкостью синтаксиса. Если это необходимо, конечно.
C>На мой взгляд править код Python не удобно, вставить пару условий и циклов в середину, , это должно видно заставить лучше относится к фазе проектирования.
Да ладно. M-x indent-region и прораб — лучший архитектор.
C>Из архитектурных преимуществ Python над Perl, то что он с самого начала был ООП(поддерживает множественное наследование даже ), а к Perl оно было потом прикручено, на взгляд многих, так же как и в PHP4, кривовато, что не мешает последним быть более популярными, видно из-за знака $
Могу согласиться. Однако, если очень хочется ООП, то тут и Пайтон, и Перл бледнеют перед Java.
Хе, похоже наш поезд все же поедет в крестовый поход.
Сильно мне хотелось попробовать Пайтон. Решил сделать маленький скрипт. Взять все файлы в директории, создать поддиректории как "имя_файла_без_расширения", скопировать туда файл. Неприятно удивился, когда пришлось импортировать три модуля, тем не менее функции из модулей все равно надо предварять именами модулей. На Перле подобная задача выполнилась бы средствами языка, без всяких модулей. Как мне его теперь переносить? Ядро Перл на windows — интерпретатор и его библиотека, два файла. А Пайтон? Как мне скрипт без модулей переносить? В общем, расстроился я. Уж молчу, как нужный модуль искать в документации.
Не то, чтобы я отрицал Пайтон как язык, возможно, я его плохо знаю. Но на мой взгляд, лучше пользоваться тем, что лучше знаешь.
Кстати, где мне найти примеры использования Пайтона для решения повседневных задач ленивого админа? Хочу сравнить.

Здравствуйте, glyph, Вы писали:

G>По сравнению с Пайтоном в этом смысле у Перла есть один плюсик: в нужный момент можно воспользоваться гибкостью синтаксиса.

Не флейма ради, а чисто интереса для: пример можно?

G>Неприятно удивился, когда пришлось импортировать три модуля, тем не менее функции из модулей все равно надо предварять именами модулей.

Не совсем так, сравни:

import a
a.foo()

from a import foo
foo()

from a import *
foo()

Но как в последнем варианте — делать не рекомендуется, дабы избежать конфликта имен.

G>На Перле подобная задача выполнилась бы средствами языка, без всяких модулей.

Ну так! Он для этого (работы с файлами) изначально и создавался.

G>Как мне его теперь переносить? Ядро Перл на windows — интерпретатор и его библиотека, два файла. А Пайтон? Как мне скрипт без модулей переносить?

Необязательно "без модулей", можно и с модулями или даже с самим питоном. Смотри distutils и py2exe — все автоматизировано. Ну а если питон на чужой машине точно стоит — можно и без модулей.

G> В общем, расстроился я. Уж молчу, как нужный модуль искать в документации.

А в чем проблема?

Здравствуйте, Пацак, Вы писали:

G>>По сравнению с Пайтоном в этом смысле у Перла есть один плюсик: в нужный момент можно воспользоваться гибкостью синтаксиса.
П>Не флейма ради, а чисто интереса для: пример можно?
Ну, под рукой примера нет, но поясню так, умозрительно — если тебе надо поиграть в perl-гольф. Если требуется сделать скрипт очень короткими. Однажды оказался в такой ситуации — под рукой только палм и gprs, ситуация внештатная, и работы было — до ЕМ. Очень порадовало, что можно извратиться — набирать что-то на пальме то еще счастье.
Пример, конечно, надуман, но идея в том, что есть выбор, как писать. Пайтон в этом смысле более ортодоксален.
G>>Неприятно удивился, когда пришлось импортировать три модуля, тем не менее функции из модулей все равно надо предварять именами модулей.
П>Но как в последнем варианте — делать не рекомендуется, дабы избежать конфликта имен.
Есть такое дело. А если мне надо из модуля импортировать десяток функций и имеется конфликт имен?
G>>На Перле подобная задача выполнилась бы средствами языка, без всяких модулей.
П>Ну так! Он для этого (работы с файлами) изначально и создавался.
Тут даже не файлы. Я бы получал вывод команд ОС, парсил бы их регекспом и снова скармливал бы ОС. Основную часть работы отдал бы ОС — ключами команд. Мб, я плохо разобрался с модулями, но в Пайтоне пришлось получить все содержимое директории, потом отобрать файлы и т.п. Нелогично как-то.
Опять же — моя субьективная точка зрения. Ничто не мешало тоже воспользоваться средствами ОС, но ведь заявлено, что есть соотв. модуль.
G>> В общем, расстроился я. Уж молчу, как нужный модуль искать в документации.
П>А в чем проблема?
Не понравились короткие описания модулей — приходится смотерть все ф-ции, чтоб узнать, что модуль может, что не может. Зато порадовала документация в CHM.
Кстати, скрипт я написал, рабочий. Только здоровый он какой-то.

Здравствуйте, glyph, Вы писали:

G> Ну, под рукой примера нет, но поясню так, умозрительно — если тебе надо поиграть в perl-гольф. Если требуется сделать скрипт очень короткими.
G> Пример, конечно, надуман, но идея в том, что есть выбор, как писать. Пайтон в этом смысле более ортодоксален.

Согласен, здесь перлу конкурентов нема. Хотя с другой стороны — разбираться в написанном таким образом месяца через два — та еще вешалка. Так что все равно более-менее приходится придерживаться "нормального" программирования. Но для задач-однодневок такой подход безусловно рулит.

G> Есть такое дело. А если мне надо из модуля импортировать десяток функций и имеется конфликт имен?

Как и в java — либо застрелиться, либо явно указывать имя модуля. Импорт модулей в питоне вообще ИМХО сильно джавовский напоминает.

Здравствуйте, fNt, Вы писали:

fNt>Здравствуйте, DemAS, Вы писали:
DAS>> Ruby и Python не знаю совсем. Вопрос такой — есть ли у этих языков преимущества для решения обозначенных выше задач? Стоит ли тратить время на их изучение(с сугубо практической точки зрения) или они по возможностям аналогичны Perl?
fNt>Я с успехом применяю именно Руби в повседневных (и, причем, аналогичных) случаях, и просто поражен чистотой и прозрачностью языка.

Использую Python для каждодневных мелочей, написания движков для сайтов и др. Доволен очень Руби не использовал,
но слышал/видел про него только хорошее. Видел, кажется всего 1 (или 2) читабельно написанных программ на Перле.
Стоит ли тратить время на изучение Перла (с сугубо практической точки зрения) или он по возможностям аналогичен Python, Ruby ?

Здравствуйте, <Аноним>, Вы писали:

А>Использую Python для каждодневных мелочей, написания движков для сайтов и др. Доволен очень Руби не использовал,
А>но слышал/видел про него только хорошее. Видел, кажется всего 1 (или 2) читабельно написанных программ на Перле.
А>Стоит ли тратить время на изучение Перла (с сугубо практической точки зрения) или он по возможностям аналогичен Python, Ruby ?

извиняюсь, улетело.
fNt>Здравствуйте, <Аноним>, Вы писали:

А>>Использую Python для каждодневных мелочей, написания движков для сайтов и др. Доволен очень Руби не использовал,
А>>но слышал/видел про него только хорошее. Видел, кажется всего 1 (или 2) читабельно написанных программ на Перле.
А>>Стоит ли тратить время на изучение Перла (с сугубо практической точки зрения) или он по возможностям аналогичен Python, Ruby ?
Мое мнение — это суть все очень близко, до взаимопроникновения, я выбрал Руби за очень понятный и читаемый вид кода, без ненужных сущностей. Я думаю все определяется привычками, ленностью и остальными 5 грехами...(или сколько их там у программеров-то?)

Здравствуйте, DemAS, Вы писали:

Всем спасибо.

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

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

Здравствуйте, glyph, Вы писали:

G> Не понравились короткие описания модулей — приходится смотерть все ф-ции, чтоб узнать, что модуль может, что не может. Зато порадовала документация в CHM.
а что мешает "опросить модуль", что он может, я про dir
G> Кстати, скрипт я написал, рабочий. Только здоровый он какой-то.
зато наверное более читаем,а не однострочники на perl

Здравствуйте, cadet354, Вы писали:

G>> Кстати, скрипт я написал, рабочий. Только здоровый он какой-то.
C>зато наверное более читаем,а не однострочники на perl

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

Здравствуйте, cadet354, Вы писали:

C>Здравствуйте, glyph, Вы писали:

G>> Не понравились короткие описания модулей — приходится смотерть все ф-ции, чтоб узнать, что модуль может, что не может. Зато порадовала документация в CHM.
C>а что мешает "опросить модуль", что он может, я про dir
Все равно по каждой функции придется разбираться отдельно. Но не в этом дело, собственно.
G>> Кстати, скрипт я написал, рабочий. Только здоровый он какой-то.
C>зато наверное более читаем,а не однострочники на perl
В общем, под настроение это ветки я его пересмотрел. Путем осознания философии Юникс и выкидывания ненужных операторов вывода на экран скрипт значительно ужался.