не нужно. Bash реализация regex'ов не очень удобна.как на счет "~~" оператора умного сравнения?
о если вам нравится -- делайте как нравится.
о если вам нравится -- делайте как нравится.
LinuxForum.Fans
Зачем учить 100500 языков? Есть же Perl!11
Автор: drBatty
60 сообщений
1229 просмотров
о если вам нравится -- делайте как нравится.
Bash реализация regex'ов не очень удобна.
для начала она в bash вообще неудобна, как и все остальное.
придерживаюсь мысли. зачем учить over9000 утилит чтобы соединять их в bash и плюс в добавок еще 100500 ключей нужно знать к каждой из них, если можно освоить один только язык perl?
если что то не прет, никто не запрещает использовать системные вызовы..
и потом, Вы сами начали php привлекать, и сказали
Это даже в php нельзя
можно выдать код, написаный на perl и получить кучу ответов, типа в bash это решается одним махом.
ну-ну.
только учтите, что вы привлекаете сторонние утилиты чтобы компенсировать код, а если разобрать эту самую утилиту?
сколько строк в её исходном коде задействовано для того, чтобы вы вот так могли одной строкой выдать результат?
готов поспорить, что для решения одной и той же задачи, один скрипт на perl будет "легче" чем скрипт написаный на баше, если учитывать в баше сторонние утилиты и внутренний код этих самых утилит, которые решают конкретную данную задачу.
да, согласен sed мощный молоток, но в нем много чего нет, это не язык, это даже не полуязык, но в нем кроется большая мощь для тривиальных задач
зачем учить over9000 утилит чтобы соединять их в bash и плюс в добавок еще 100500 ключей нужно знать к каждой из них, если можно освоить один только язык perl?
Зачем учить perl, если можно учить python, который уделывает perl по популярности, размеру сообщества, количеству модулей из коробки, количеству сторонних модулей и либ вообще и т.д. и т.п. ? :)
Или даже так. Зачем учить что-то кроме C, если можно взять и запилить на C свою реализую пайтона/перла/чего_угодно. Чтобы уж наверняка. А то вдруг не оптимальный вариант получится. *CRAZY* *ROFL*
С системному админу вообще не нужен.
а по обработке текста верблюд уделает змею, одни только regex возьми, в них можно и задачи решать и вообще любой код делать.
в прочем можно сделать рекурсивный код в регулярке, который сам для себя будет генерировать pattern, а в питоне это можно?
популярность вообще ни разу не поможет
а по обработке текста верблюд уделает змею, одни только regex возьми, в них можно и задачи решать и вообще любой код делать.
в прочем можно сделать рекурсивный код в регулярке, который сам для себя будет генерировать pattern, а в питоне это можно?
На обработке текста задачи не заканчиваются. Ага.
Тулкит для созданий гуев есть встроенный у perl? А у python есть. Помимо этого, есть врапперы для всех популярных тулкитов, включая qt, gtk и wxwidgets.
Обработку изображений "из коробки" perl умеет? А вот python умеет.
С HTTP, FTP, XML-RPC, SMTP, IMAP, NNTP умеет perl работать "из коробки"? А python это все поддерживает "из коробки".
Помимо этого python "из коробки" работает с архивами, базами данных, имеет криптографический модуль в "стандартной поставке" и т.д.
И да, я сам python не пользуюсь вообще. Так, для сравнения с perl привел. Если уж разговор пошел про
зачем учить over9000 утилит чтобы соединять их в bash ... если можно освоить один только язык perl?
То из выше написанного, и perl незачем осваивать. По возможностям Python его уделывает. Единственная область, где perl может тягаться - обработка громадных объемов текста.
если во главе сидят .... я то тут при чем?
Правила не надо было нарушать, тогда был бы не при чем.
ага. И ещё 133,109 Perl modules. Действительно, я не знаю, что "лучше". ИМХО лучше всё-же bash, потому что Linux надо сначала поставить, а потом админить. Теми самыми утилитами, про которых вы слышать не хотите. А придётся.придерживаюсь мысли. зачем учить over9000 утилит чтобы соединять их в bash и плюс в добавок еще 100500 ключей нужно знать к каждой из них, если можно освоить один только язык perl?
утилита нужна сама по себе. Не только в bash'е. Кстати, некоторые утилиты в GNU Linux написаны на perl'е.только учтите, что вы привлекаете сторонние утилиты чтобы компенсировать код, а если разобрать эту самую утилиту?
сколько строк в её исходном коде задействовано для того, чтобы вы вот так могли одной строкой выдать результат?
и что? Эти утилиты более универсальны, и потому сложнее. Часто они ещё и на порядок быстрее. И на порядок меньше жрут. Ну и они уже есть.готов поспорить, что для решения одной и той же задачи, один скрипт на perl будет "легче" чем скрипт написаный на баше, если учитывать в баше сторонние утилиты и внутренний код этих самых утилит, которые решают конкретную данную задачу.
ваш ник вам соответствует. Это Тьюринг-полный ЯП. Погуглите, что это значит. Если на пальцах, то на sed можно написать что угодно. Хоть ядро Linux + bash + сам perl.да, согласен sed мощный молоток, но в нем много чего нет, это не язык, это даже не полуязык
для любых задач. Это доказано.но в нем кроется большая мощь для тривиальных задач
что-бы знать, что perl по всем этим параметрам уделывает питон :)Зачем учить perl, если можно учить python, который уделывает perl по популярности, размеру сообщества, количеству модулей из коробки, количеству сторонних модулей и либ вообще и т.д. и т.п. ?
я сильно сомневаюсь, что ваша реализация той же sort на C будет хотя-бы в 10 раз медленнее моей на каком-нить php.Или даже так. Зачем учить что-то кроме C, если можно взять и запилить на C свою реализую пайтона/перла/чего_угодно. Чтобы уж наверняка. А то вдруг не оптимальный вариант получится.
можно.в прочем можно сделать рекурсивный код в регулярке, который сам для себя будет генерировать pattern, а в питоне это можно?
что-бы знать, что perl по всем этим параметрам уделывает питон
У тебя уделывает - флаг в руки. У moshellа вон perl вообще все на свете уделывает, я не против, пусть уделывает. Главное - с пеной у рта мне этого не доказывайте, мне до фени, честно :)
я сильно сомневаюсь, что ваша реализация той же sort на C будет хотя-бы в 10 раз медленнее моей на каком-нить php.
Не надо выдергивать отдельные фразы из контекста.
Речь была о
зачем учить over9000 утилит чтобы соединять их в bash
если
можно освоить один только язык perl?
и причиной было названо
сколько строк в её исходном коде задействовано для того, чтобы вы вот так могли одной строкой выдать результат?
готов поспорить, что для решения одной и той же задачи, один скрипт на perl будет "легче" чем скрипт написаный на баше, если учитывать в баше сторонние утилиты и внутренний код этих самых утилит
Соответственно, если товарищ так переживает за количество строк в каждой из задействованных утилит, скриптов и т.д. то пусть тогда все с нуля пилит, а то не дай бог где-нибудь встретится лишняя строчка или не оптимальная реализация, это же, согласно его словам, так плохо.
при чём тут я? Я не фанат перловки, но перловка намного старше, и батареек для неё понаписали в разы больше. С этим глупо спорить, один CPAN чего стоит. А то, что этого нет в коробке как раз хорошо. На кой ляд мне в каждом приложении свои QRcodes?У тебя уделывает - флаг в руки.
сложно спорить с очевидным, но у вас почти получилось. (:Главное - с пеной у рта мне этого не доказывайте, мне до фени, честно
тогда непонятно, с какого боку тут ЯП? В каждом ЯП есть свои батарейки, в bash'е тоже. Вот только разница в том, что bash-батарейки создавались 40 лет, и за эти годы доведены до совершенства. В bash'е чуть-ли не каждая батарейка является чуть-ли не полноценным ЯП (а некоторые типа sed без всякого "чуть-ли"). Ну да, код созданный гуру конечно без поллитры не разобрать, особенно если этот гуру любит писать 80% кода на ЯП из нужной батарейки. Ну что поделать, в принципе код на любом другом ЯП написанный гуру тоже не разобрать начинающему. Питон и перловка не исключение. И php тоже(только в php гуру практически нет, потому и считается "простым").Соответственно, если товарищ так переживает за количество строк в каждой из задействованных утилит, скриптов и т.д. то пусть тогда все с нуля пилит, а то не дай бог где-нибудь встретится лишняя строчка или не оптимальная реализация, это же, согласно его словам, так плохо.
Ну а вообще, если на то пошло, то идеальный ЯП для новичок безусловно brainfuсk.
Я не фанат перловки, но перловка намного старше, и батареек для неё понаписали в разы больше. С этим глупо спорить, один CPAN чего стоит.
Не спорю, но поддерживаются ли до сих пор все эти батарейки. И так ли легко в чужом перло-коде n лет выдержки разобраться. Тут уж каждый сам для себя пусть ответ выбирает, кому и что проще будет. Тем более, что количество решений для других языков тоже разрослось достаточно, есть из чего выбрать.
На кой ляд мне в каждом приложении свои QRcodes?
Кто заставляет что ли модуль с ними подключать-то в каждом приложении? =)
В Python модули же не загружены по умолчанию при выполнении приложения, нужен конкретный модуль - делаешь import модуль, не нужен - просто не вспоминаешь про него.
тогда непонятно, с какого боку тут ЯП? В каждом ЯП есть свои батарейки, в bash'е тоже. Вот только разница в том, что bash-батарейки создавались 40 лет, и за эти годы доведены до совершенства. В bash'е чуть-ли не каждая батарейка является чуть-ли не полноценным ЯП (а некоторые типа sed без всякого "чуть-ли"). Ну да, код созданный гуру конечно без поллитры не разобрать, особенно если этот гуру любит писать 80% кода на ЯП из нужной батарейки. Ну что поделать, в принципе код на любом другом ЯП написанный гуру тоже не разобрать начинающему.
Ну так это не мне, а местному обожателю perl'а объяснять надо. Он же предлагает при каждом удобном случае пользователям отказаться от всех рабочих проверенных временем решений, ради их же реализации на perl под каким-то сомнительным предлогом.
ага. Можно подумать, что в питоне оно лучше. Сколько %% батареек уже умеют питон3? Ну вот -- то то же.Не спорю, но поддерживаются ли до сих пор все эти батарейки.
ну а в перловке ещё круче: если модуль не нужен, он так и лежит в недрах cpan.org. А не в вашем /usr.В Python модули же не загружены по умолчанию при выполнении приложения, нужен конкретный модуль - делаешь import модуль, не нужен - просто не вспоминаешь про него.
ну это я ему и писал в общем-то. Ну и вообще всем фанатегам любого ЯП.Ну так это не мне, а местному обожателю perl'а объяснять надо.
Сколько %% батареек уже умеют питон3?
а зачем, если есть 2.7? ах незачем?
Ну вот -- то то же.
мы про поддержку батареек говорили.а зачем, если есть 2.7?
мы про поддержку батареек говорили.
и про третий пайтон, который никто не использует
мы про поддержку батареек говорили.
и про третий пайтон, который никто не использует
дык я и говорю, что третий никто не юзает потому, что нет батареек. А батареек нет потому, что никто не юзает. Fail.
один юникод это уже повод хоронить 2.х.а зачем, если есть 2.7?
один юникод это уже повод хоронить 2.х.
Однако, Eddy_Em почему-то UTF люто ненавидит и зовет эту кодировку не иначе как "хрюникод".
sudo cast Eddy_Em :)
очевидно по тому, что он никогда не разрабатывал ПО способное обрабатывать информацию более чем на двух языках. Вот весело: в файле встретилось слово українська, и...Однако, Eddy_Em почему-то UTF люто ненавидит
Кстати он сам использует вот такой смайл: ☺
про юникод в питоне: http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/
один юникод это уже повод хоронить 2.х.
a что с ним не так? я сам писал на пайтоне патчи с поддержкой юникода, на 2.6 есличто
Войдите или зарегистрируйтесь, чтобы ответить.
