Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 182
Чем хорош Perl?
Perl вырабатывает навыки ручной обфускации кода по ходу написания
Perl вырабатывает навыки ручной обфускации кода по ходу написания
В среднем, если не брать мелкие проекты то код чаще читают чем пишут.
Именно поэтому
my @arr = qw/aaa bbb ccc/;
Я бы не назвал более простым способом, а скорее боле сложным.
Именно поэтому
my @arr = qw/aaa bbb ccc/;
Я бы не назвал более простым способом, а скорее боле сложным.
Меньше строк — больше помещается на экране, легче читать. Нет?
Нет, же. Иначе бы все программисты бы сидели с перевернутыми ЖК мониторами. Строк-то больше.
Более того, обявление
my @arr = («aaa», «bbb», «ccc»);
… как правило понятно людям котоыре и не знают перла, но знают другие языки, а вот ваш вариант может поствить в тупик.
Да и экономия на спичках какая-то. Посмотрите статистику сколько в среднем пишеться строчек кода в проектах. В тех конторах в которых я работал результат был не больше 80 новых строчек в день на человека — если брать всю стадию проекта от начала до релиза, при проектах от полугода.
Если мы непосредственно само написание ускорим раза в два — то выйграем мизер, который легко потеряеться как только мы не там поставим скобочку.
Более того, обявление
my @arr = («aaa», «bbb», «ccc»);
… как правило понятно людям котоыре и не знают перла, но знают другие языки, а вот ваш вариант может поствить в тупик.
Да и экономия на спичках какая-то. Посмотрите статистику сколько в среднем пишеться строчек кода в проектах. В тех конторах в которых я работал результат был не больше 80 новых строчек в день на человека — если брать всю стадию проекта от начала до релиза, при проектах от полугода.
Если мы непосредственно само написание ускорим раза в два — то выйграем мизер, который легко потеряеться как только мы не там поставим скобочку.
Дело не только в том, как объявляются массивы. Наличие готового модуля в CPAN, например, экономит тысячи строк кода.
Вы все правильно говорите. Само программирование, как
известно, занимает в лучшем случае 30% времени всей разработки, так что синтаксис по большому счету ни на что не влияет.
Но важно помнить, что это справедливо только в том случае, если речь идет о крупном проекте. В большинстве случаев мне приходится писать небольшие, до 100 строк кода, программы. Вот тут синтаксис весьма важен.
Вы все правильно говорите. Само программирование, как
известно, занимает в лучшем случае 30% времени всей разработки, так что синтаксис по большому счету ни на что не влияет.
Но важно помнить, что это справедливо только в том случае, если речь идет о крупном проекте. В большинстве случаев мне приходится писать небольшие, до 100 строк кода, программы. Вот тут синтаксис весьма важен.
Если мы ускорим раза в 2 написание, то останется больше времени на продумывание хороших алгоритмов и интересных решений. У вас странный стереотип что программирование — тупо набивание большого количества текста. Как раз это неправильно.
Опять же не все языки должны быть похожи друг на друга, иначе не будет прогресса. Потому понимать с первого раза любой листинг не является первоцелью программирования.
P.S. чтобы не пропускать скобочки нужно пользоваться редакторами с подсветкой синтаксиса
Опять же не все языки должны быть похожи друг на друга, иначе не будет прогресса. Потому понимать с первого раза любой листинг не является первоцелью программирования.
P.S. чтобы не пропускать скобочки нужно пользоваться редакторами с подсветкой синтаксиса
Да написание кода это и так мизер. Ну будет на 7 минут больше в день?
Зато в прекрасный момент вам нужно будет отрефакторить код в котором поучаствовало десяток программистов и вы поймете, что возможность объявть массив десятков способов это миф — ибо все равно нужно сделать так чтобы в проекте использовался только один. Вы поймете что из-за гибкого синтаксиса у вас нету нормальных инструментов для рефакторинга.
Зато в прекрасный момент вам нужно будет отрефакторить код в котором поучаствовало десяток программистов и вы поймете, что возможность объявть массив десятков способов это миф — ибо все равно нужно сделать так чтобы в проекте использовался только один. Вы поймете что из-за гибкого синтаксиса у вас нету нормальных инструментов для рефакторинга.
> обявление
> my @arr = («aaa», «bbb», «ccc»);
> … как правило понятно людям котоыре и не знают перла
Но мы же про perl говорим. При чём тут люди, которые не знают перла? Зачем им вообще программировать на языке, который они не знают?
Вы немного не с той стороны смотрите на гибкость синтаксиса :) Если Вы знаете язык, то Вам будет по барабану как объявили массив, Вы и так и так легко поймёте чего происходит в строке.
А когда нужно объявить достаточно много «однословных» элементов, то часто удобнее использовать qw//, чем каждое слово брать в кавычки и разделять запятыми. Плюс когда надо между двумя хешами обменяться значениями определённых ключей, опять гораздо удобнее использовать срез и «обозначить» его через qw// — одна строка и всё готово :) А без этого придётся либо прописывать «обмен значения» по каждому ключу отдельно, либо заводить хеш с соответствиями ключей из двух хешей, которые «обмениваются» и потом прогонять всё через цикл — такой способ будет понятен многим и его легко будет дополнить дополнительными ключами для «обмена», но для знающих perl вариант со срезом массива будет так же понятен и так же удобен ;)
> my @arr = («aaa», «bbb», «ccc»);
> … как правило понятно людям котоыре и не знают перла
Но мы же про perl говорим. При чём тут люди, которые не знают перла? Зачем им вообще программировать на языке, который они не знают?
Вы немного не с той стороны смотрите на гибкость синтаксиса :) Если Вы знаете язык, то Вам будет по барабану как объявили массив, Вы и так и так легко поймёте чего происходит в строке.
А когда нужно объявить достаточно много «однословных» элементов, то часто удобнее использовать qw//, чем каждое слово брать в кавычки и разделять запятыми. Плюс когда надо между двумя хешами обменяться значениями определённых ключей, опять гораздо удобнее использовать срез и «обозначить» его через qw// — одна строка и всё готово :) А без этого придётся либо прописывать «обмен значения» по каждому ключу отдельно, либо заводить хеш с соответствиями ключей из двух хешей, которые «обмениваются» и потом прогонять всё через цикл — такой способ будет понятен многим и его легко будет дополнить дополнительными ключами для «обмена», но для знающих perl вариант со срезом массива будет так же понятен и так же удобен ;)
Кстати, вспоминается эмпирическое правило, согласно которому количество ошибок на 1000 строк кода — константа, независимо от используемого языка.
если вы знаете Perl, то такая штука вам будет прекрасно понятна. А если не знаете — то зачастую не сможете до конца понять весь код на Perl даже если умеете отлично программировать на десятке других языков. Perl выразителен. Крайне выразителен, что очень хорошо, если это использовать по делу. Можно конечно состряпать на перле ТАКОЕ, которое никто не прочитает с ходу. Например: paste.ubuntu.com/354022/
Мне лично куда как более импонирует
my @arr = qw/aaa bbb ccc/;
нежели
my @arr = («aaa», «bbb», «ccc»);
Ибо легко добавить ещё один элемент и кавычки не мешаются. ИМХО, читается первый вариант проще, если конечно знать, что qw — это оператор закавычивания. Кстати, можно так:
my @arr = qw(aaa bbb ccc);
Или даже так:
my @arr = qw#aaa bbb ccc#;
Опять-таки, вы всегда сможете написать так, чтобы ваш код читался великолепно, при этом оставаясь элегантным и простым. На других языках такого обычно сделать нельзя.
Мне лично куда как более импонирует
my @arr = qw/aaa bbb ccc/;
нежели
my @arr = («aaa», «bbb», «ccc»);
Ибо легко добавить ещё один элемент и кавычки не мешаются. ИМХО, читается первый вариант проще, если конечно знать, что qw — это оператор закавычивания. Кстати, можно так:
my @arr = qw(aaa bbb ccc);
Или даже так:
my @arr = qw#aaa bbb ccc#;
Опять-таки, вы всегда сможете написать так, чтобы ваш код читался великолепно, при этом оставаясь элегантным и простым. На других языках такого обычно сделать нельзя.
и что этот верблюд делает при запуске?
Выводит такого же верблюда, только символом #.
Не только. Слишком много символов для такой банальнейшей операции)))
А вы что, запустили?))) А если бы там было rm -rf /?))))
Вот полный список параметров запуска:
perl camel.pl normal camel
perl camel.pl q quine (program prints itself)
perl camel.pl m mirror (camel looking in the mirror)
perl camel.pl i inverted camel
perl camel.pl u upside-down camel
perl camel.pl r rotated camel
perl camel.pl h horizontally-squashed camel
perl camel.pl v vertically-squashed camel
А вы что, запустили?))) А если бы там было rm -rf /?))))
Вот полный список параметров запуска:
perl camel.pl normal camel
perl camel.pl q quine (program prints itself)
perl camel.pl m mirror (camel looking in the mirror)
perl camel.pl i inverted camel
perl camel.pl u upside-down camel
perl camel.pl r rotated camel
perl camel.pl h horizontally-squashed camel
perl camel.pl v vertically-squashed camel
Вы знаете, многие говорят что ПХП код на перле длинней, но это ведь не так, в ПХП столько функций понаделывали, что комбинируя их можно очень сильно уменьшить строки кода… только смысл? мне всегда казалось что «изящный» и «компактный» не одно и то-же, красивый код может быть и большим, главное чтоб его понимали другие а не Вы
Изящный — это не только алгоритм, это ещё и способ его представления, понятный в читабельном виде. Функции — это просто способ группировки инструкций, они одинаковы во всех языках (хотя не, такой гибкости, как Perl и Python тоже практически никто функциям не обеспечивает).
Например, на Perl можно написать
if ($is_alpha) {
print «something»;
}
а можно
if ($is_alpha) { print «something»}
или вообще
print «something» if $is_alpha;
Или классическое
open INFILE, ">file.txt" or die «File error»;
Всякие такие штуки позволяют не отвлекаться на извороты с скудным жестким синтаксисом конструкций, а писать именно то, что имеешь ввиду. Приём если это делать грамотно, то читабельность всего этого будет сильно выше, чем у PHP и даже Python.
Например, на Perl можно написать
if ($is_alpha) {
print «something»;
}
а можно
if ($is_alpha) { print «something»}
или вообще
print «something» if $is_alpha;
Или классическое
open INFILE, ">file.txt" or die «File error»;
Всякие такие штуки позволяют не отвлекаться на извороты с скудным жестким синтаксисом конструкций, а писать именно то, что имеешь ввиду. Приём если это делать грамотно, то читабельность всего этого будет сильно выше, чем у PHP и даже Python.
На заборе «х...» написано, но его там нет.
В Perl столько модулей, что комбинируя их можно ещё сильнее код сократить чем в PHP, а можно и расширить функционал не сильно напрягаясь, а учитывая синтаксический сахар языка ещё и получить удовольствие от этого процесса.
Поймут ли ваш код или нет это больше от культуры программирования зависит нежели от языка, на любом языке программирования можно такое наворотить, волосы дыбом встанут. Сейчас в Perl принято в любых программах использовать strict синтаксис, потому с понятностью всё в порядке.
В Perl столько модулей, что комбинируя их можно ещё сильнее код сократить чем в PHP, а можно и расширить функционал не сильно напрягаясь, а учитывая синтаксический сахар языка ещё и получить удовольствие от этого процесса.
Поймут ли ваш код или нет это больше от культуры программирования зависит нежели от языка, на любом языке программирования можно такое наворотить, волосы дыбом встанут. Сейчас в Perl принято в любых программах использовать strict синтаксис, потому с понятностью всё в порядке.
Да не можете.
Потому что как только ваши проекты вырастут из студенческих и вам нужно будет работать в команде — у вас будет только один способ обявить массив. Ибо никто будуче в своем уме не позволит тащить в проект код написанный десятком способов.
Потому что как только ваши проекты вырастут из студенческих и вам нужно будет работать в команде — у вас будет только один способ обявить массив. Ибо никто будуче в своем уме не позволит тащить в проект код написанный десятком способов.
Во-первых, с точки зрения Perl человек предоставил всего 2 способа описания массивов,
во-вторых, в команде в любом случае надо иметь какой либо документ с нормативами синтаксиса который в проекте используется и будет использоваться
во-вторых, в команде в любом случае надо иметь какой либо документ с нормативами синтаксиса который в проекте используется и будет использоваться
да еще и по контексту (такой феномен в Perl) можно догадаться что подразумевается работа с массивом:
say $_ .' is my bitch' foreach qw( надя катя маргарита );
а еще есть опубликованные справочники по ЯП. иногда полезно туда заглянуть если вышел за пределы обычного средненького ЯП
say $_ .' is my bitch' foreach qw( надя катя маргарита );
а еще есть опубликованные справочники по ЯП. иногда полезно туда заглянуть если вышел за пределы обычного средненького ЯП
Угу, нужно — и почему-то мне кажеться что этот способ будет —
my @arr = («aaa», «bbb», «ccc»);
Как наиболее явный.
my @arr = («aaa», «bbb», «ccc»);
Как наиболее явный.
Это какой человек в здравом уме опишет в требованиях столь неиспользуемую вещь как заполнение массива при создании?))))
Вот, чуть ниже давали ссылочку:
www.reg.ru/coding_standards
По этим требованиям можно и постфиксные конструкции вставлять, и уж тем более qw использовать, не говоря уже об удобных ограничителях вместо //. Собственно просто глупо ограничивать в требованиях к коду особенности языка, призванные как раз увеличить читабельность этого самого кода. Я понимаю запрет на $_ и всякие другие $x, они создают большую путаницу, но разумное использование всего остального — это только плюсы кодирования.
Вот, чуть ниже давали ссылочку:
www.reg.ru/coding_standards
По этим требованиям можно и постфиксные конструкции вставлять, и уж тем более qw использовать, не говоря уже об удобных ограничителях вместо //. Собственно просто глупо ограничивать в требованиях к коду особенности языка, призванные как раз увеличить читабельность этого самого кода. Я понимаю запрет на $_ и всякие другие $x, они создают большую путаницу, но разумное использование всего остального — это только плюсы кодирования.
> my @arr = qw/aaa bbb ccc/;
Может я чего-то не понимаю, но что если я захочу добавить в этот массив элемент, содержащий пробел? например «ff ee»? в этом случае этот элемент интерпретатором будет рассматриваться как 2 элемента: ff и ее ??
в чем же тогда изящество?
Может я чего-то не понимаю, но что если я захочу добавить в этот массив элемент, содержащий пробел? например «ff ee»? в этом случае этот элемент интерпретатором будет рассматриваться как 2 элемента: ff и ее ??
в чем же тогда изящество?
А если один из элементов массива состоит из нескольких слов, разделенных пробелом?
delete
Извините за офтоп. Но когда будут нормально в университетах преподавать? я имею ввиду актуальные предметы??? Кто сможет ответить???
Актуальные предметы актуально изучать самому;)
Та и делаю. Просто обидно: учишь 5 лет какую-то мутоту, разве не так???? Я не пойму, это проблема постсоветской системы образования или это во всех технических универах???
Я знаю много людей, не имеющих высшего образования и никак от этого не страдающих. Если бы не оставалось учиться пол года, я задумался бы над тем, чтобы забить (благо с армией проблем у меня уже вроде нет).
Дело в том что многие при поступлении в университеты, еще не знаю чего хотят и к чему стремиться, поэтому делают обширную программу, чтоб даже те кто пошел на администрирование (как я в данном случае) в принципе могли переквалифицироваться безболезненно на смежные професии.
потому как при поступлении я и понятия не имел что буду вебом заниматься, педалил себе на десктопе, и Была бы специальность программист делфи, я бы на нее пошел бы :). А так сам перепробовал всякого многого, выбрал себе стезю и пошел дальше, универ не мешает
потому как при поступлении я и понятия не имел что буду вебом заниматься, педалил себе на десктопе, и Была бы специальность программист делфи, я бы на нее пошел бы :). А так сам перепробовал всякого многого, выбрал себе стезю и пошел дальше, универ не мешает
То что люди не знают чего хотят это ещё пол беды, большей проблемой является то что люди поступая на факлььтеты где в названии говорится что-то про программистов или компьютеры (я сам учусь на факультете математик и компьютерных наук, однако дальше паскаля копьютерынх наук пока не видно), не то что программировать совсем не умеют, а многие даже файл из папки в папку скопировать не могут. И куда им IT специалистами быть?
А разве поступают в учебные заведения не для того, чтобы там учиться, в том числе и «файл из папки в папку скопировать»?
Мне всё-таки кажется что если человек не владеет даже эллементарными навыками пользования компьютером, то на факультете математики и КОМПЬЮТЕРНЫХ НАУК ему делать явно нечего.
Тем более, почему из за того что они этого не умеют, лично я должен целый год слушать какю-то ерунду про пользование «виндоузом» и вордом, вместо того что-бы получить хоть толику каких то новых и полезных знаний?
Тем более, почему из за того что они этого не умеют, лично я должен целый год слушать какю-то ерунду про пользование «виндоузом» и вордом, вместо того что-бы получить хоть толику каких то новых и полезных знаний?
Честно говоря не знаю, какая сейчас программа в средних школах по информатике (мы на каком-то русском ЯП чего-то кодили), но всё что выше её должны преподавать в ВУЗе, отрыва от школьной программы быть не должно. Вы свою «ерунду про пользование «виндоузом» и вордом» в школе проходили на уроках или дополнительно где-то (хоть дома «методом тыка») занимались? И чтобы вы сказали, если, например, на математике вам сразу бы стали давать, скажем, операционное исчисление, на том основании, что кто-то готов их изучать, а в школе вы лично даже интегралы не проходили?
У меня в школе мы играли на уроках в CS и доту, однако в программе чётко значилось изучение опять же какой то «ерунды про пользование «виндоузом» и вордом»
Если уж на то пошло, то я вообще не пойму в чём суть круса «ерунды про пользование «виндоузом» и вордом», потому что не вижу смысла ИЗУЧАТЬ в университетах — ВЫСШИХ УЧЕБНЫХ ЗАВЕДЕНИЯХ программы с интуитивно понятным интерфейсом. И я с девятого класса сам по себе занимаюсь веб программированием хотя меня этому никто никогда не учил.
И если-бы нам дали сразу операционное исчисление вместо того чтобы пол первого семестра считать производные я бы был всеми руками за, потому что если кто-то чего-то не освоил в школьной программе, то это его проблемы а не мои. Моя задача — это получить максимум знаний за минимум времени, а не работать ходячим справочником по функциям паскаля и пунктам меню екселя для однагруппников.
Уж не подумайте что я какой-то ботаник и сильно любителяь математики — просто я считаю не эффективным те методы образования которые имеют место быть.
Как можно научить людей программирровать обучая их функциям паскаля и как там окна открывать, вместо того чтобы рассказать азы алгоритмизации? Ведь большенство даже цикл составить не могут.
Я уж и не говорю про то, чтобы изучать какой-то другой, нормальный язык, я понимаю что есть учебные планы и всё такое, и их никто не хочет переписывать. Но заниматься программированием с «маетматическим уклоном» на языке в котором нет функции возведения числа в произвольную степень — на мой взгляд просто возмутительно.
Если уж на то пошло, то я вообще не пойму в чём суть круса «ерунды про пользование «виндоузом» и вордом», потому что не вижу смысла ИЗУЧАТЬ в университетах — ВЫСШИХ УЧЕБНЫХ ЗАВЕДЕНИЯХ программы с интуитивно понятным интерфейсом. И я с девятого класса сам по себе занимаюсь веб программированием хотя меня этому никто никогда не учил.
И если-бы нам дали сразу операционное исчисление вместо того чтобы пол первого семестра считать производные я бы был всеми руками за, потому что если кто-то чего-то не освоил в школьной программе, то это его проблемы а не мои. Моя задача — это получить максимум знаний за минимум времени, а не работать ходячим справочником по функциям паскаля и пунктам меню екселя для однагруппников.
Уж не подумайте что я какой-то ботаник и сильно любителяь математики — просто я считаю не эффективным те методы образования которые имеют место быть.
Как можно научить людей программирровать обучая их функциям паскаля и как там окна открывать, вместо того чтобы рассказать азы алгоритмизации? Ведь большенство даже цикл составить не могут.
Я уж и не говорю про то, чтобы изучать какой-то другой, нормальный язык, я понимаю что есть учебные планы и всё такое, и их никто не хочет переписывать. Но заниматься программированием с «маетматическим уклоном» на языке в котором нет функции возведения числа в произвольную степень — на мой взгляд просто возмутительно.
Если действительно в государственном стандарте по школьной информатике (или как там его) есть то, что вы сейчас проходите, то да, это повод, как минимум, для возмущения. Но, судя по всему, это ваши проблемы, что вы опередили программу и теперь вам скучно, в конце концов сдайте экстерном.
Насчёт того, что преподают часто то, что давно не актуально на рынке — согласен, и это давняя проблема, нам вон преподавали Фортран на СМ-1420, в то время когда индустрия вовсю осваивала С++ на «виндоуз».
Насчёт того, что преподают часто то, что давно не актуально на рынке — согласен, и это давняя проблема, нам вон преподавали Фортран на СМ-1420, в то время когда индустрия вовсю осваивала С++ на «виндоуз».
В го стандарте — хз, а вот в документах которые у нас были — точно было. Причём что интеерсно, помимо ворда, там ещё и регламентировалось преподаваление Корол Драва, паскаля, и кучи чего ещё. Естественно ничего из этого не делалось. Вся проблема в том что преподаватель даже не умела делать таблицы в ворде, не то что что-то там преподавать)
А уж если говорить о математик — так там ещё больший разброд, потому что те же люди, которые не умеют копировать файлы, дойдя до третьего курса так и не могут ответить на вопрос а что же такое единичный эллемент группы или скажем скалярное произведение. А слова типо гоморфный образ группы, или скажем Ядро дирихле — вызывают у них просто приступ паники. Это вам не файлы копирвоать.
Я просто это к чему, что разруха — всё-таки восновном в головах. В головах как обучаемых так и обучающих, кстати.
Я просто это к чему, что разруха — всё-таки восновном в головах. В головах как обучаемых так и обучающих, кстати.
Сам заканчиваю институт и прихожу к выводу, что никогда. Хотите чему-то научиться, покупайте книжки. Инвестиции в себя всегда окупаются © afiskon.
Когда средний по больнице преподаватель начнет получать вкусную зарплату и за его место будет драка.
Сейчас образование в полной жопе кто бы что бы не вещал по телевизору и становится только хуже.
Сейчас образование в полной жопе кто бы что бы не вещал по телевизору и становится только хуже.
«Объявления о имеющейся вакансии Perl-программиста появляются с большой частотой» улыбнуло. Вакансии перлоидов есть. Причем самые разнообразные — от обезьянок до настоящах гуру (таких работодатель дожидается много месяцев). Про частоту можете подробнее рассказать?
Ну полистайте сообщество ru_perl к примеру — там чуть ли не на каждой странице вакансии то в Mail.ru то в Рамблер.
За рынком пристально наблюдаю (сам какбэ профессиональный perl decoder/encoder) и недавно менял место работы. Так что усомнился в большой частоте. На мой взгляд вполне обоснованно усомнился. В дефолт-сити более или менее часто требуются знатоки, в питере значительно хуже спрос, периферия обычно удаленка или Perl требуется вместе с десятком других языков (которые обезьянка знает весьма поверхностно).
«Это печально».
«Это печально».
Perl хороший язык, но с выделением памяти по моему у него явные проблемы.
Вот тестовый примерчик:
use strict;
use warnings;
use Time::HiRes qw/gettimeofday/;
my $time = gettimeofday();
my $i;
my $s;
for ($i=0; $i<1000000; $i++) {
$s .= $i;
}
print gettimeofday() - $time;
то-же на PHP в разы быстрее, это при первом запуске, при последующих запусках (FastCGI) Perl обгонит PHP в 2 раза, но платой за это будет зарезервированный блок памяти.
P.S. тестил под Windows
Вот тестовый примерчик:
use strict;
use warnings;
use Time::HiRes qw/gettimeofday/;
my $time = gettimeofday();
my $i;
my $s;
for ($i=0; $i<1000000; $i++) {
$s .= $i;
}
print gettimeofday() - $time;
то-же на PHP в разы быстрее, это при первом запуске, при последующих запусках (FastCGI) Perl обгонит PHP в 2 раза, но платой за это будет зарезервированный блок памяти.
P.S. тестил под Windows
Знаете, мне кажется это из серии написать Hello World на ассемблере и C++ и утверждать, что ассемблер лучше, потому что на нем программа занимает 1 Кб, а на C++ 30 Кб.
Реальные задачи рассматривать нужно…
Реальные задачи рассматривать нужно…
Я не утверждаю, что что-то лучше. Я просто констатирую факт, если в Web приложении будет много конкатенации строк, то Perl будет тормозить при выделении доп памяти в отличие от PHP.
Я не утверждаю, что вы утверждаете, что что-то лучше :)
Я говорю, что если вас беспокоит вопрос, какой интерпретатор производительнее, то нужно смотреть реальные задачи, а не гипотетический cgi-cкрипт, который почему-то вместо того, чтобы работать с БД и делать подстановку в html-шаблон, делает миллион конкатенаций.
Вот например, упомянутый Movable Type решает ту же задачу, что и WordPress, но при этом менее требователен к ресурсам. Возникает закономерный вопрос — это проблема реализации или языка? И можно ли отнести проблему реализации к проблеме уровню комьюнити и следовательно — языка.
Я говорю, что если вас беспокоит вопрос, какой интерпретатор производительнее, то нужно смотреть реальные задачи, а не гипотетический cgi-cкрипт, который почему-то вместо того, чтобы работать с БД и делать подстановку в html-шаблон, делает миллион конкатенаций.
Вот например, упомянутый Movable Type решает ту же задачу, что и WordPress, но при этом менее требователен к ресурсам. Возникает закономерный вопрос — это проблема реализации или языка? И можно ли отнести проблему реализации к проблеме уровню комьюнити и следовательно — языка.
Вы забывали к своим утверждениям добавить «под Windows».
Мысль другая — либо он работает быстрее при дополнительном выделении памяти, либо медленнее без него.
Опять же я писал выше — в Perl в основном работают со списками, потому как таковых конкатенаций в коде в разы меньше.
Опять же я писал выше — в Perl в основном работают со списками, потому как таковых конкатенаций в коде в разы меньше.
Извините, не удержался:
Hello World на асме будет занимать 21 байт :) Из них 13 байт — сама строка «Hello, world!»
Можно наверное попробовать в 20 байт вместить.
что-то в духе:
mov dl, 07h; absolute offset of string
mov ah, 09h
int 21h
iret
Hello, world!; даже меньше получилось, 19
Hello World на асме будет занимать 21 байт :) Из них 13 байт — сама строка «Hello, world!»
Можно наверное попробовать в 20 байт вместить.
что-то в духе:
mov dl, 07h; absolute offset of string
mov ah, 09h
int 21h
iret
Hello, world!; даже меньше получилось, 19
my $s; # этот скаляр затребует некоторое колическо RAM — неизбежность
# а здесь простой flip-flop генерирующий ряд целых чисел
$s .= $_ for 0… 999999;
# а здесь простой flip-flop генерирующий ряд целых чисел
$s .= $_ for 0… 999999;
$s .= $_ for 0 .. 999999; # две точки вместо трех
ой. вы правы. конечно две точки (… — «flip-flop» оператор для перлоидов и символ верхнего мира для юниксоидов) подразумевались
… — «flip-flop» оператор для перлоидов и символ верхнего мира для юниксоидов.
теперь правильно! %)
теперь правильно! %)
Во-первых, здесь видимо умничает парсер хабра и подставляет HTML entity ellipsis (…) оно же троеточие, вместо двух подряд идущих точек. Во-вторых в данном случае в Perl две точки обозначают range operator, функциональность flip-flop — это только в скалярном контексте. В-третьих, три точки, как подставил хабр — тоже можно и в данном случае это не меняет поведение кода.
Вот за это (тонкие отличия между… и ...) перл и не любят.
У меня данный код выполняется за ~0.2 sec. Аналогичный PHP код — за 0.35 sec. Система FreeBSD.
У меня код MikeGav выполняется в среднем 0.53 секунды, код JIP — в среднем 0.46 секунды. Аналогичный код на PHP — в среднем 0.55. FreeBSD 6.4-RELEASE-p7
Конкатенация строки числами от 1 до 3000000
Первый пуск из под FastCGI
PHP ~ 1.8051040172577
Strawberry Perl ~ 51.734375
Последующие запуски из под FastCGI
PHP ~ 1.8051040172577
Strawberry Perl ~ 0.640625
При этом у PHP каждый запуск начинает с новой жизнью, и заканчивается высвобождением памяти.
Perl ведет себя как полноценное FCGI приложение память выделил и не отдает. Но не это здесь главное, хотелось бы чтобы allocate памяти был таким-же быстрым.
Да и как отписались выше скорее всего и в правду виновата реализация под Windows, буду смотреть под nix :)
Первый пуск из под FastCGI
PHP ~ 1.8051040172577
Strawberry Perl ~ 51.734375
Последующие запуски из под FastCGI
PHP ~ 1.8051040172577
Strawberry Perl ~ 0.640625
При этом у PHP каждый запуск начинает с новой жизнью, и заканчивается высвобождением памяти.
Perl ведет себя как полноценное FCGI приложение память выделил и не отдает. Но не это здесь главное, хотелось бы чтобы allocate памяти был таким-же быстрым.
Да и как отписались выше скорее всего и в правду виновата реализация под Windows, буду смотреть под nix :)
Опять же в нормальной программе на Perl такой код совсем маловероятен, ибо в Perl в основном оперируют списками и хешами данных, потому данный пример совсем некорректен.
Опять же будет зарезервирован блок памяти = ~5-6 Мб, поставил PHP у себя запустил при каждом запуске подобного скрипта столько же и тратиться, только каждый раз при выполнении дополнительно нагружается процессор
Опять же будет зарезервирован блок памяти = ~5-6 Мб, поставил PHP у себя запустил при каждом запуске подобного скрипта столько же и тратиться, только каждый раз при выполнении дополнительно нагружается процессор
Хм, приведу следующий тест (Windows/ActivePerl)
Benchmark: timing 10 iterations of JOIN, LOOP…
JOIN: 1 wallclock secs ( 1.36 usr + 0.00 sys = 1.36 CPU) @ 7.35/s (n=10)
LOOP: 12 wallclock secs ( 7.81 usr + 3.27 sys = 11.08 CPU) @ 0.90/s (n=10)
Вариант с join быстрее в 8 раз
#!/usr/bin/perl -w
use strict;
use Benchmark qw(timethese);
timethese(10, {
'LOOP' => q[
my $i;
my $s;
for ($i=0; $i<1000000; $i++) {
$s .= $i;
}
],
'JOIN' => q[
my $s = join '', (1..1000000);
],
});
1;
__END__
Benchmark: timing 10 iterations of JOIN, LOOP…
JOIN: 1 wallclock secs ( 1.36 usr + 0.00 sys = 1.36 CPU) @ 7.35/s (n=10)
LOOP: 12 wallclock secs ( 7.81 usr + 3.27 sys = 11.08 CPU) @ 0.90/s (n=10)
Вариант с join быстрее в 8 раз
Лично я работаю с Perl-ом, потому что на нем написана OpenCore — аутгейм бот для Рагнарок Онлайн. Подчеркну бот, а не сайт. Очень доволен как перлом, так и ботом.
Точно так же учил и LUA — программирую бота. Рекомендую такой способ изучения :)
Точно так же учил и LUA — программирую бота. Рекомендую такой способ изучения :)
вакансии:
reg.ru/company/jobs-prog
по DBIx::Class трудно найти крупные подборки материалов. так что обычная документация с CPAN или perldoc
Catalyst — помимо CPAN и perldoc есть две (из известных мне) книги. самая свежая релизнулось летом 2009 года:
amazon.com/Catalyst-Accelerating-Perl-Application-Development/dp/1847190952
amazon.com/Definitive-Guide-Catalyst-Maintainable-Applications/dp/1430223650/ref=pd_sim_b_1
избранные ресурсы по языку:
ironman.enlightenedperl.org/
twitter.com/planetperlru
reg.ru/company/jobs-prog
по DBIx::Class трудно найти крупные подборки материалов. так что обычная документация с CPAN или perldoc
Catalyst — помимо CPAN и perldoc есть две (из известных мне) книги. самая свежая релизнулось летом 2009 года:
amazon.com/Catalyst-Accelerating-Perl-Application-Development/dp/1847190952
amazon.com/Definitive-Guide-Catalyst-Maintainable-Applications/dp/1430223650/ref=pd_sim_b_1
избранные ресурсы по языку:
ironman.enlightenedperl.org/
twitter.com/planetperlru
Viva Perl
В список литературы «С чего начать изучение Perl?», я бы еще добавил книгу
Perl Best Practices (Damian Conway, 2005)
Чтобы не писать как вздумается, а придерживаться какого-то стиля.
Perl Best Practices (Damian Conway, 2005)
Чтобы не писать как вздумается, а придерживаться какого-то стиля.
«A little anal-retention never hurt...» — так выразил свое отношение к прагме strict один из CPAN-авторов :)
Я рекомендую Perl::Critic — можно обернуть в свой удобный хеппер проекта или даже прекоммит-хук. Сильное дисциплинирующее средство. Причем репорты которые генерирует Perl::Critic ссылаются на страницы книги Perl Best Practices. Получаем нечто вроде код-ревьювера обитающего в машине.
Я рекомендую Perl::Critic — можно обернуть в свой удобный хеппер проекта или даже прекоммит-хук. Сильное дисциплинирующее средство. Причем репорты которые генерирует Perl::Critic ссылаются на страницы книги Perl Best Practices. Получаем нечто вроде код-ревьювера обитающего в машине.
к чёрту perl, учите python!
> PHP имеет свои преимущества, многие из которых вытекают из простоты его синтаксиса.
Относительно Perl. см. Lisp. 7 правил.
> Простой синтаксис, значит прост в изучении.
Тоже неправда. См. туда же. На Common Lisp.
Относительно Perl. см. Lisp. 7 правил.
> Простой синтаксис, значит прост в изучении.
Тоже неправда. См. туда же. На Common Lisp.
Мы все знаем объективные факты:
— количество развиваемых проектов на Perl снижается;
— количество Perl разработчиков снижается;
— активность Perl разработчиков снижается;
— т.к. Perl разработчиков все меньше, труд их все дороже, и т.к. все тенденции ведут к снижению уровня использования этого языка, начинать новый коммерческий проект на нем — это, если не безумие, то по крайней мере очень опасный ход;
— отказ от Perl для новых коммерческих продуктов замыкает цикл с предыдущим пунктом, фактически вытесняя этот язык в зону «языков для домашнего использования» или зону «Just for fun».
При этом мы все делаем вид что ничего не происходит, Perl все так же розов и свеж, как и 10 лет назад, все пишется в 3 строчки и все великолепно.
Улыбаемся и машем!
— количество развиваемых проектов на Perl снижается;
— количество Perl разработчиков снижается;
— активность Perl разработчиков снижается;
— т.к. Perl разработчиков все меньше, труд их все дороже, и т.к. все тенденции ведут к снижению уровня использования этого языка, начинать новый коммерческий проект на нем — это, если не безумие, то по крайней мере очень опасный ход;
— отказ от Perl для новых коммерческих продуктов замыкает цикл с предыдущим пунктом, фактически вытесняя этот язык в зону «языков для домашнего использования» или зону «Just for fun».
При этом мы все делаем вид что ничего не происходит, Perl все так же розов и свеж, как и 10 лет назад, все пишется в 3 строчки и все великолепно.
Улыбаемся и машем!
Хм, что же мне учить сейчас для unix-разработки, если python/php не хочется, а в C# уверенности нет? Неужели скучной Java?
Кстати, у них там страшный провал в абсолютных цифрах 2009 года. Неужели кризис?
Кстати, у них там страшный провал в абсолютных цифрах 2009 года. Неужели кризис?
Я буду жать кнопку предпросмотра. Я буду жать кнопку предпросмотра. Я буду жать кнопку предпросмотра. Я буду жать кнопку предпросмотра.
И даже читать буду, что понаписал. Неужели?
И даже читать буду, что понаписал. Неужели?
Что значит «не хочется»? Если хочется зарабатывать на хлеб с маслом и икрой именно программированием, то надо учить то на что есть спрос.
Для unix-разработки, кстати, можно хоть C учить — без работы не останетесь.
Для unix-разработки, кстати, можно хоть C учить — без работы не останетесь.
Не хочется — значит не хочется. Зарабатывать надо с удовольствием.
Но вот в какой же язык перетекают все потенциальные перловые проекты? Размываются между php/python/ruby?
Но вот в какой же язык перетекают все потенциальные перловые проекты? Размываются между php/python/ruby?
Но вот в какой же язык перетекают все потенциальные перловые проекты? Размываются между php/python/ruby?
За все проекты, конечно, сказать нельзя, но их большинство — да.
Зарабатывать с удовольствием — это правильно. Но во-первых вы зря мешаете python и php в одну кучу — это очень разные языки.
А во-вторых можете изучить старые добрые C/C++, которые вряд ли потеряют в близком будущем актуальность, хотя бы потому, что на них пишется львиная часть системного ПО.
>зря мешаете python и php в одну кучу — это очень разные языки.
Не сказал бы, что очень разные по сути языки. Более-менее современные интерпретируемые языки с динамической типизацией, по-моему, не могут быть сильно разными. Оба поддерживают (хотя и в разной мере) императивное, процедурное, объектно-ориентированное и даже функциональное программирование. Код на пайтоне, как правило, более лаконичен и элегантен, но большинство конструкций, имхо, просто синтаксический сахар, легко реализующийся на пехепе. Создавать новый проект на python php-программист (не тот, который стал «программистом», прочитав пару книжек «PHP4 для чайников за 24 часа») может через пару дней после знакомства с новым языком, пускай и напишет больше кода, чем напишет python-программист и этот код для python-программиста будет выглядеть не очень оптимально, в частности из-за привычки работать с «универсальным» массивом, а не со «специализированными» списками, кортежами и словарями, ну и незнание стандартных библиотек тоже скажется. Но сам подход к реализации алгоритма, по-моему, общий в большинстве языков, если не считать совсем «нетрадиционные» типа Lisp или Forth
P.S. Всё вышесказанное относится прежде всего к веб-программированию, всё-таки использовать серьезно PHP в других целях не самый лучший вариант
Не сказал бы, что очень разные по сути языки. Более-менее современные интерпретируемые языки с динамической типизацией, по-моему, не могут быть сильно разными. Оба поддерживают (хотя и в разной мере) императивное, процедурное, объектно-ориентированное и даже функциональное программирование. Код на пайтоне, как правило, более лаконичен и элегантен, но большинство конструкций, имхо, просто синтаксический сахар, легко реализующийся на пехепе. Создавать новый проект на python php-программист (не тот, который стал «программистом», прочитав пару книжек «PHP4 для чайников за 24 часа») может через пару дней после знакомства с новым языком, пускай и напишет больше кода, чем напишет python-программист и этот код для python-программиста будет выглядеть не очень оптимально, в частности из-за привычки работать с «универсальным» массивом, а не со «специализированными» списками, кортежами и словарями, ну и незнание стандартных библиотек тоже скажется. Но сам подход к реализации алгоритма, по-моему, общий в большинстве языков, если не считать совсем «нетрадиционные» типа Lisp или Forth
P.S. Всё вышесказанное относится прежде всего к веб-программированию, всё-таки использовать серьезно PHP в других целях не самый лучший вариант
Если не хочется сейчас — можно и на перле писать, всё-таки на нём ещё достаточно много пишут.
Можно посмотреть на перл6, вдруг он тоже станет популярным через какие-то 5 лет :)
А вообще unix-разработка на столько абстрактный термин, что любой язык может быть неподходящим :)
Можно посмотреть на перл6, вдруг он тоже станет популярным через какие-то 5 лет :)
А вообще unix-разработка на столько абстрактный термин, что любой язык может быть неподходящим :)
>Хм, что же мне учить сейчас для unix-разработки
а что именно вы собрались писать под unix?
>Неужели скучной Java?
посмотрите на наскучные jvm-языки типа groovy/scala/clojure
а что именно вы собрались писать под unix?
>Неужели скучной Java?
посмотрите на наскучные jvm-языки типа groovy/scala/clojure
Это у вас выборка специфическая. Зайдите на dice.com и посмотрите.
java — 9698
c# — 4582
c++ — 4164
perl — 3247
php — 1639
python — 1308
ruby — 688
cobol — 530
java — 9698
c# — 4582
c++ — 4164
perl — 3247
php — 1639
python — 1308
ruby — 688
cobol — 530
Моя выборка показывает динамику и активность в проектах, но да, вы правы, специфика ее заключается в том, что рассматриваются лишь OpenSource проекты.
Однако, ваша выборка не менее специфична. Ее специфика заключается в том, что вы рассматриваете сиюминутный срез по требуемым специалистам.
В этом есть некоторая доля лукавства:
Во-первых, эти данные отражают потребность рынка, а не активность использования языка. Потребность рынка в cobol специалистах может быть, например, обусловлена вовсе не широтой его использования, а тем, что этих специалистов просто мало, и их трудно найти.
Во-вторых, эти данные отражают потребность в специалистах как для поддержки существующих проектов, так и для создания новых. А эти понятия не стоит смешивать в одну кучу.
Поясню более подробно последний тезис:
Допустим, рынку сейчас требуется 530 высококлассных специалистов для поддержки проекта на cobol и 1639 для поддержки проекта на php. При этом на cobol они требуются для поддержки legacy проектов, а на php, допустим 60% для поддержки проектов существующих и 40% для создания новых.
Вопрос:
Что произойдет, если на рынок вдруг придет количество программистов, вдвое больше требуемого?
Например, 1000 программистов на cobol и 3000 программистов на php?
— 530 cobol программистов заполнят потребность рынка, и оставшиеся 470 останутся у разбитого корыта, т.к. все legacy проекты уже поддерживаются, а новых не предвидится.
— 1639 php программистов заполнят потребность рынка, а оставшиеся хоть и останутся первоначально без работы, но найдут ее по мере открытия новых проектов на этом языке (возможно, временно подрабатывая на фрилансе).
Выводы
Показатель востребованности того или иного навыка, безусловно, важен. Важен, наверно, ничуть не меньше, чем популярность этого инструмента. Но эти показатели нельзя сравнивать, как нельзя сравнивать мощность двигателя с объемом бензобака.
Таким образом, приведенные вами данные следует не противопоставлять приведенным графикам, а трактовать как дополнительную информацию, уточняющую первоначальное высказывание:
«Несмотря на снижение популярности Perl-a, на западном рынке сохраняется относительно высокий спрос на Perl программистов».
Однако, ваша выборка не менее специфична. Ее специфика заключается в том, что вы рассматриваете сиюминутный срез по требуемым специалистам.
В этом есть некоторая доля лукавства:
Во-первых, эти данные отражают потребность рынка, а не активность использования языка. Потребность рынка в cobol специалистах может быть, например, обусловлена вовсе не широтой его использования, а тем, что этих специалистов просто мало, и их трудно найти.
Во-вторых, эти данные отражают потребность в специалистах как для поддержки существующих проектов, так и для создания новых. А эти понятия не стоит смешивать в одну кучу.
Поясню более подробно последний тезис:
Допустим, рынку сейчас требуется 530 высококлассных специалистов для поддержки проекта на cobol и 1639 для поддержки проекта на php. При этом на cobol они требуются для поддержки legacy проектов, а на php, допустим 60% для поддержки проектов существующих и 40% для создания новых.
Вопрос:
Что произойдет, если на рынок вдруг придет количество программистов, вдвое больше требуемого?
Например, 1000 программистов на cobol и 3000 программистов на php?
— 530 cobol программистов заполнят потребность рынка, и оставшиеся 470 останутся у разбитого корыта, т.к. все legacy проекты уже поддерживаются, а новых не предвидится.
— 1639 php программистов заполнят потребность рынка, а оставшиеся хоть и останутся первоначально без работы, но найдут ее по мере открытия новых проектов на этом языке (возможно, временно подрабатывая на фрилансе).
Выводы
Показатель востребованности того или иного навыка, безусловно, важен. Важен, наверно, ничуть не меньше, чем популярность этого инструмента. Но эти показатели нельзя сравнивать, как нельзя сравнивать мощность двигателя с объемом бензобака.
Таким образом, приведенные вами данные следует не противопоставлять приведенным графикам, а трактовать как дополнительную информацию, уточняющую первоначальное высказывание:
«Несмотря на снижение популярности Perl-a, на западном рынке сохраняется относительно высокий спрос на Perl программистов».
Хотите динамику, смотрите.
Тренд на понижение я на этом графике вижу только у cobol. Так что ваши утверждения «о снижении популярности Perl-а» с реальностью несколько расходятся. Остальные же ваши рассуждения очень похожы на усиленное притягивание фактов за уши к уже сформированному у вас мнению с помощью пространных домыслов.
Тренд на понижение я на этом графике вижу только у cobol. Так что ваши утверждения «о снижении популярности Perl-а» с реальностью несколько расходятся. Остальные же ваши рассуждения очень похожы на усиленное притягивание фактов за уши к уже сформированному у вас мнению с помощью пространных домыслов.
Ну что ж, готов признать свою неправоту: похоже, что в области Enterprise вы правы и Perl на самом деле чувствует себя хорошо.
Если вы учтете тот факт, что ohloh отслеживает всего около 1000 проектов имеющих отношение к Perl при том, что только на CPAN зарегистрировано 77 708 модулей, то может быть поймете, что и в open source у Perl все не так плохо как вам показалось. Для сравнения, на сегодня python имеет 8639 пакетов, ruby — 9253 gem'ов, PHP PEAR — совсем смешные 547 пакетов.
>perl — 3247
при этом «чистый» перл там уже странице на пятой почти заканчивается, т.е. перл либо идёт в нагрузку, либо (что реже) альтернативным языком к php/python, итого получается чуть ли не на порядок меньше, т.е. всего 300 вакансий. Если не верите — сделайте поиск как «Search job title only»:
java — 3083
c++ — 823
c# — 900
perl — 167(!)
php — 292
при этом «чистый» перл там уже странице на пятой почти заканчивается, т.е. перл либо идёт в нагрузку, либо (что реже) альтернативным языком к php/python, итого получается чуть ли не на порядок меньше, т.е. всего 300 вакансий. Если не верите — сделайте поиск как «Search job title only»:
java — 3083
c++ — 823
c# — 900
perl — 167(!)
php — 292
>perl — 3247
при этом «чистый» перл там уже странице на пятой почти заканчивается, т.е. перл либо идёт в нагрузку, либо (что реже) альтернативным языком к php/python, итого получается чуть ли не на порядок меньше, т.е. всего 300 вакансий
Вы выборку из этих данных какую делали? Открывали каждую вакансию типа 'Software Developer' или 'Software Engineer' без указания языка? Или просто сделали предположение что это не Perl и дальше пятой страницы не смотрели? Объясните, на основании каких данных вы решили отбросить >3000 вакансий (95% процентов)? Вы уверены что среди отброшенных вами вакансий не найдется еще пары сотен вполне релевантных Perl вакансий (я вот нашел случайным тыком такую даже на 25-ой странице)?
Если не верите — сделайте поиск как «Search job title only»:
java — 3083
c++ — 823
c# — 900
perl — 167(!)
php — 292
Это можно объяснить например тем, что примерно половина вакансий для Perl не имеет названия языка в job title. См. jobs.perl.org — из 20 вакансий в title Perl упоминается у 12 (~60%). Для сравнения, phpjobs.com — из 12 релевантных вакансий в title PHP упоминается у всех (100%).
>Вы выборку из этих данных какую делали? Открывали каждую вакансию типа 'Software Developer' или 'Software Engineer' без указания языка? Или просто сделали предположение что это не Perl и дальше пятой страницы не смотрели?
посмотрел 5 страницу, 6, 10 и парочку после 10.
>Объясните, на основании каких данных вы решили отбросить >3000 вакансий (95% процентов)?
даже если и есть ещё пара сотен, как вы предлагаете их выискивать? Как бы сам dice.com сортирует вакансии по релевантности…
>я вот нашел случайным тыком такую даже на 25-ой странице
исключение, подтверждающее правило?
>Это можно объяснить например тем, что примерно половина вакансий для Perl не имеет названия языка в job title. См. jobs.perl.org — из 20 вакансий в title Perl упоминается у 12 (~60%)
половина VS 10% — приличная разница, не находите ли?
посмотрел 5 страницу, 6, 10 и парочку после 10.
>Объясните, на основании каких данных вы решили отбросить >3000 вакансий (95% процентов)?
даже если и есть ещё пара сотен, как вы предлагаете их выискивать? Как бы сам dice.com сортирует вакансии по релевантности…
>я вот нашел случайным тыком такую даже на 25-ой странице
исключение, подтверждающее правило?
>Это можно объяснить например тем, что примерно половина вакансий для Perl не имеет названия языка в job title. См. jobs.perl.org — из 20 вакансий в title Perl упоминается у 12 (~60%)
половина VS 10% — приличная разница, не находите ли?
>Вы выборку из этих данных какую делали? Открывали каждую вакансию типа 'Software Developer' или 'Software Engineer' без указания языка? Или просто сделали предположение что это не Perl и дальше пятой страницы не смотрели?
посмотрел 5 страницу, 6, 10 и парочку после 10.
Т.е. сами вакансии не открывали?
>Объясните, на основании каких данных вы решили отбросить >3000 вакансий (95% процентов)?
даже если и есть ещё пара сотен, как вы предлагаете их выискивать?
Если вы отбрасываете больше половины значимых данных — то ваши итоговые результаты недостоверны.
>я вот нашел случайным тыком такую даже на 25-ой странице
исключение, подтверждающее правило?
посмотрел еще на 10-ой,11-ой,53-ей страницах — нашел соответственно 1, 2 и 1 релевантные вакансии.
Как бы сам dice.com сортирует вакансии по релевантности…
Релевантность, судя по всему, там однобитная — «упоминается в title»/«упоминается в body», поэтому после 5-ой страницы релевантные вакансии размазаны равномерно по оставшейся сотне страниц.
>Это можно объяснить например тем, что примерно половина вакансий для Perl не имеет названия языка в job title. См. jobs.perl.org — из 20 вакансий в title Perl упоминается у 12 (~60%)
половина VS 10% — приличная разница, не находите ли?
Вы о чем, поясните?
Что можно сказать…
* Программы, написанные на Perl (как и в случае с любым другим скриптовым языком), одинаково хорошо работают под разными операционными системами.
Все не так просто. Программы хорошо работают, если использовать модули из CPAN, самые полезные из которых требуют компиляции кода на C, а следовательно зависят о платформы. Как пример — ActiveState Perl под windows не имеет драйвера для Postgresql, его надо искать отдельно и не факт, что у вас он заработает =)
* Зачастую то, что на другом языке программирования (например, PHP) занимает десять строк кода может быть написано на Perl в одну строчку.
Но есть и минусы. Другому человеку будет сложновато сходу понять, что делает эта строчка. Perl (в отличие от java, например) требует отличной организованности и дисциплины. Иначе ваш код в легкую превратиться в китайскую лапшу.
* Если перед вами стоит какая-то задача, загляните в CPAN. Скорее всего, кто-то уже решил ее. Вам остается лишь скачать модуль и прочитать документацию к нему.
CPAN это отлично для UNIX систем. Под Windows… будьте готовы к неожиданностям.
* Программы, написанные на Perl (как и в случае с любым другим скриптовым языком), одинаково хорошо работают под разными операционными системами.
Все не так просто. Программы хорошо работают, если использовать модули из CPAN, самые полезные из которых требуют компиляции кода на C, а следовательно зависят о платформы. Как пример — ActiveState Perl под windows не имеет драйвера для Postgresql, его надо искать отдельно и не факт, что у вас он заработает =)
* Зачастую то, что на другом языке программирования (например, PHP) занимает десять строк кода может быть написано на Perl в одну строчку.
Но есть и минусы. Другому человеку будет сложновато сходу понять, что делает эта строчка. Perl (в отличие от java, например) требует отличной организованности и дисциплины. Иначе ваш код в легкую превратиться в китайскую лапшу.
* Если перед вами стоит какая-то задача, загляните в CPAN. Скорее всего, кто-то уже решил ее. Вам остается лишь скачать модуль и прочитать документацию к нему.
CPAN это отлично для UNIX систем. Под Windows… будьте готовы к неожиданностям.
strawberry perl вроде бы успешно собирает цпановские модули, за исключением конечно плаформозависимого C
Все нужные, как правило, зависят от C. общем с разными платформами у perl дела не фонтан. Так-же как и мало удовольствия ставить модули из cpan, когда есть пакетные менеджеры в linux. Та-же Java в этом отношении более удобна. Тот-же самый CPAN aka Maven, только он ещё и сборщик и линковщик и на-все-руки-мастер. Плюс в итоге мы получаем готовый jar/war/ear пакет, в котором упакованы все библиотеки-ресурсы. В перле есть PAR, да только кто им пользуется?
Во-первых, насчет всех нужных вы существенно преувеличиваете. Я лично не испытываю особых затруднений при разработке приложений, которые используют только pure-Perl модули. Из зависимых от C модулей часто нужен только DBD::mysql или DBD::Pg.
Во-вторых, ничто не мешает вам ставить perl-модули с помощью пакетных менеджеров, а не через cpan. Для FreeBSD к примеру есть pm2port, который создает FreeBSD port из Perl-модуля.
В-третьих, а что вам мешает использовать тот же Maven с Perl-приложением? Я лично так вообще Rake использую для сборки, запуска тестов, deploy и т.п.
В-четвертых, если вы не пользуетесь PAR, то это не значит что никто им не пользуется.
Во-вторых, ничто не мешает вам ставить perl-модули с помощью пакетных менеджеров, а не через cpan. Для FreeBSD к примеру есть pm2port, который создает FreeBSD port из Perl-модуля.
В-третьих, а что вам мешает использовать тот же Maven с Perl-приложением? Я лично так вообще Rake использую для сборки, запуска тестов, deploy и т.п.
В-четвертых, если вы не пользуетесь PAR, то это не значит что никто им не пользуется.
В пятых я никому не пожелаю переносить крупный Perl проект с Linux на Windows, особенно если в нем куча модулей из CPAN. Хорошо, если это ваш проект, типа сайт, который всегда будет работать на одном сервере и у него один хозяин. А если у вас тиражируемый продукт?
>Я лично не испытываю особых затруднений при разработке приложений, которые используют только pure-Perl модули
Я наверное не ошибусь, если замечу, что даже внутри самого банального perl-date-time модуля есть замечательные файлы DateTime.bs и DateTime.so? На pure perl они не очень тянут.
Пример не самый лучший, потому-что модуль известный и в готовом виде есть везде. Но если например в проект взять довольно шустрый движок темплейтов ClearSilver (http://www.clearsilver.net/), который написан на C++ и имеет обертку к Perl, то может так вдруг оказаться, что в вашей новой версии ОС нет готового модуля для этого движка. В прошлой был, в новой — нет. Увы, случай из реальной жизни, я уже молчу про Windows.
Так-что вопрос с зависимыми от платформы модулями для Perl не теряет актуальности.
Как собственно и вопрос удобства их использования. Ведь если в CPAN начать устанавливать один модуль, вдруг окажется, что у него в зависимостях ещё пять, и у этих пяти есть свои зависимости — во славу компилятора make. Хотя несомненно, что большая часть этих модулей есть в пакетах. В общем, ещё то удовольствие.
Я повторюсь, вопрос затрагивает исключительно кросплатформенность Perl. В Linux таких проблем вы наверняка не встретите.
>Я лично не испытываю особых затруднений при разработке приложений, которые используют только pure-Perl модули
Я наверное не ошибусь, если замечу, что даже внутри самого банального perl-date-time модуля есть замечательные файлы DateTime.bs и DateTime.so? На pure perl они не очень тянут.
Пример не самый лучший, потому-что модуль известный и в готовом виде есть везде. Но если например в проект взять довольно шустрый движок темплейтов ClearSilver (http://www.clearsilver.net/), который написан на C++ и имеет обертку к Perl, то может так вдруг оказаться, что в вашей новой версии ОС нет готового модуля для этого движка. В прошлой был, в новой — нет. Увы, случай из реальной жизни, я уже молчу про Windows.
Так-что вопрос с зависимыми от платформы модулями для Perl не теряет актуальности.
Как собственно и вопрос удобства их использования. Ведь если в CPAN начать устанавливать один модуль, вдруг окажется, что у него в зависимостях ещё пять, и у этих пяти есть свои зависимости — во славу компилятора make. Хотя несомненно, что большая часть этих модулей есть в пакетах. В общем, ещё то удовольствие.
Я повторюсь, вопрос затрагивает исключительно кросплатформенность Perl. В Linux таких проблем вы наверняка не встретите.
В пятых я никому не пожелаю переносить крупный Perl проект с Linux на Windows, особенно если в нем куча модулей из CPAN. Хорошо, если это ваш проект, типа сайт, который всегда будет работать на одном сервере и у него один хозяин. А если у вас тиражируемый продукт?
Я три года был ведущим разработчиком тиражируемого коммерческого проекта на Perl. В качестве рабочего окружения продукта поддерживается и ActivePerl 5.6+ и shared hosting. Продукт использует несколько десятков pure Perl модулей со CPAN (всего около 10 Мб). Из внешних обязательных зависимостей только DBD::mysql. Опционально продукт может использовать внешние HTML::Parser, MIME::Tools, Net::DNS, perl-LDAP и GD — эти модули и их зависимости обнаруживаются автоматически и соответствующие опции становятся доступными в настройках.
>Я лично не испытываю особых затруднений при разработке приложений, которые используют только pure-Perl модули
Я наверное не ошибусь, если замечу, что даже внутри самого банального perl-date-time модуля есть замечательные файлы DateTime.bs и DateTime.so? На pure perl они не очень тянут. Пример не самый лучший, потому-что модуль известный и в готовом виде есть везде.
Обратите внимание на файл DateTimePP.pm в том же пакете — буквы PP означают pure-Perl. XS версия опциональна.
Но если например в проект взять довольно шустрый движок темплейтов ClearSilver (http://www.clearsilver.net/), который написан на C++ и имеет обертку к Perl, то может так вдруг оказаться, что в вашей новой версии ОС нет готового модуля для этого движка. В прошлой был, в новой — нет. Увы, случай из реальной жизни, я уже молчу про Windows.
Мне так кажется, что если у проекта среди требований стоит на первом месте переносимость, то и модули надо выбирать в первую очередь по этому критерию, а потом уже по шустрости или удобству. У меня, например, используется HTML::Template, я сильно матерился первое время после Template Toolkit. Сейчас привык, и даже извлек из его использование пользу — примитивность HTML::Template сразу отучает городить какой-либо код в шаблонах.
Как собственно и вопрос удобства их использования. Ведь если в CPAN начать устанавливать один модуль, вдруг окажется, что у него в зависимостях ещё пять, и у этих пяти есть свои зависимости — во славу компилятора make. Хотя несомненно, что большая часть этих модулей есть в пакетах. В общем, ещё то удовольствие.
У меня на данный момент в системе установлен 571 перловый модуль. Из них только 9 собраны из локально созданных мной портов, остальные из системных. Напрямую со CPAN поставлено ни одного модуля.
Я повторюсь, вопрос затрагивает исключительно кросплатформенность Perl. В Linux таких проблем вы наверняка не встретите.
Я рассматриваю shared hosting на каком-нибудь протухшем RHEL 3 как более сложную в поддержке платформу нежели чем ActivePerl 5.8+ на self-managed сервере, поскольку подмножество pure Perl модулей значительно меньше, нежели доступные в виде ppm модули (с учетом дополнительных репозитариев)
Все классно, когда изначально все просчитываешь. У меня три год тому задача была другая — перетащить объемный perl проект с linux на windows, т.е. сделать типа коробочный продукт под несколько операционных систем, что бы его мог установить не сильно продвинутый эндюзер (в идеале эндюзер-окновод). Натрахался, слов нет. Оно даже между разными линуксами переносилось с проблемами, некоторые пакеты перловых модулей были в репах убунту, но их не было в репах suse или мандрейка, приходилось выяснять все эти тонкости, недостающее в репах пакеты собирать с помощью cpan2rpm или cpan2deb и включать в дистрибутив, часть модулей пришлось менять и переписывать код для упрощения этой самой кросплатформенности.
Уточню для фанатов холиваров, я не завявляю, что perl не кросплатформенный, я говорю, что с этим есть определенные проблемы, особенно если вы изначально не задумывались об этом.
Уточню для фанатов холиваров, я не завявляю, что perl не кросплатформенный, я говорю, что с этим есть определенные проблемы, особенно если вы изначально не задумывались об этом.
вы не поняли, собирается на windows С нормально, за исключеним тех XS в которых явно используются плаформозависимые инклюды итд.
Слушайте, можно ведь и мамонта вручную по атомам собрать, но думаю, что это малоприятное удовольствие, под Windows сначала надо собрать среду для сборки, потом уже собирать модули с помощью этой среды…
я ж написал выше.
strawberryperl.com/
strawberryperl.com/
Да, кстати. С ООП в дефолтовом перле не очень. Только через дополнительные модули из CPAN, а это зависимость от платформы (модули на C++) и от самих модулей.
Сильно не хватает аналога mod_php. Без него приходится трудится, что-бы делать быстрый код. Есть конечно mod_perl, он помогает. Но это отдельный объемный мирок, который надо уметь использовать.
Ещё с Unicode есть заморочки. Хотя они, имхо, везде есть. Я когда-то наивно думал, что хоть в корпоративно-прогрессивной Java их не будет, а куда там.
И как маленький итог, я после десяти лет веб-программирования на perl перешел на Java. Ничем не хуже, одни плюсы. А Perl остается отличным вспомогательным инструментом, для написания скриптов-помощников.
Сильно не хватает аналога mod_php. Без него приходится трудится, что-бы делать быстрый код. Есть конечно mod_perl, он помогает. Но это отдельный объемный мирок, который надо уметь использовать.
Ещё с Unicode есть заморочки. Хотя они, имхо, везде есть. Я когда-то наивно думал, что хоть в корпоративно-прогрессивной Java их не будет, а куда там.
И как маленький итог, я после десяти лет веб-программирования на perl перешел на Java. Ничем не хуже, одни плюсы. А Perl остается отличным вспомогательным инструментом, для написания скриптов-помощников.
Чего именно вам не хватает в перле в возможностях ООП?
Неплохо описано в статье habrahabr.ru/blogs/perl/59512/
Для ООП есть модуль Mouse — легкая версия Moose. Не имеет зависимостей и может быть собран без XS части, т.е. pure-Perl.
mod_perl дает намного больше возможностей нежели mod_php. В качестве тупой запускалки по типу mod_php сейчас есть mod_perlite и он уже может исполнять Movable Type.
С Unicode никаких особых заморочек в Perl 5.6+ не встречал, достаточно внимательно прочитать man perluniintro и остальное, а потом аккуратно делать decode на входе текста и encode на выходе.
mod_perl дает намного больше возможностей нежели mod_php. В качестве тупой запускалки по типу mod_php сейчас есть mod_perlite и он уже может исполнять Movable Type.
С Unicode никаких особых заморочек в Perl 5.6+ не встречал, достаточно внимательно прочитать man perluniintro и остальное, а потом аккуратно делать decode на входе текста и encode на выходе.
>Для ООП есть модуль Mouse — легкая версия Moose. Не имеет зависимостей и может быть собран без XS части, т.е. pure-Perl.
Есть, это обертка над ООП оберткой. Да, реально делает жизнь интересней а код слаще, только не отменяет факт, что perl не задумывался как ООП язык. Я собственно против ничего не имею, просто в свое время предпочел изучить Java, а не Mouse/Moose.
>mod_perl дает намного больше возможностей нежели mod_php.
А так ли нужны возможности в угоду сложности? Я сделал упор именно на простоту mod_php, не секрет, что благодаря ему php скрипты под apache работают шустрее чем скрипты на perl.
>В качестве тупой запускалки по типу mod_php сейчас есть mod_perlite и он уже может исполнять Movable Type.
Ему уже года три-четыре им по очереди занимается то один то другой энтузиаст и этот проект все-ещё в стадии вау-проекта. Типа, вау! Он вроде-бы смог запустить Movable Type!
>С Unicode никаких особых заморочек в Perl 5.6+ не встречал, достаточно внимательно прочитать man perluniintro и остальное, а потом аккуратно делать decode на входе текста и encode на выходе.
А это не заморочки? Лично я встречал ещё год назад. Как пример — куча модулей, включая TemplateToolkit не знают, что есть на свете юникод, особенно это затрагивает чтение-запись в файлы. Поэтому приходилось либо искать по мейллистам плагины (tt2) либо переписывать модули.
Потом начинаются заморочки. Перл с юникодом странно работает, он может получать юникод, но не подозревать об этом если у строки не проставлен флаг, что это юникод. Т.е. в реальности надо постоянно заботится во всех слоях между которыми идет обмен данными — web, db, perl, regexp, file i/o, stdin, stdout… Это не смертельно, но иногда злит.
Есть, это обертка над ООП оберткой. Да, реально делает жизнь интересней а код слаще, только не отменяет факт, что perl не задумывался как ООП язык. Я собственно против ничего не имею, просто в свое время предпочел изучить Java, а не Mouse/Moose.
>mod_perl дает намного больше возможностей нежели mod_php.
А так ли нужны возможности в угоду сложности? Я сделал упор именно на простоту mod_php, не секрет, что благодаря ему php скрипты под apache работают шустрее чем скрипты на perl.
>В качестве тупой запускалки по типу mod_php сейчас есть mod_perlite и он уже может исполнять Movable Type.
Ему уже года три-четыре им по очереди занимается то один то другой энтузиаст и этот проект все-ещё в стадии вау-проекта. Типа, вау! Он вроде-бы смог запустить Movable Type!
>С Unicode никаких особых заморочек в Perl 5.6+ не встречал, достаточно внимательно прочитать man perluniintro и остальное, а потом аккуратно делать decode на входе текста и encode на выходе.
А это не заморочки? Лично я встречал ещё год назад. Как пример — куча модулей, включая TemplateToolkit не знают, что есть на свете юникод, особенно это затрагивает чтение-запись в файлы. Поэтому приходилось либо искать по мейллистам плагины (tt2) либо переписывать модули.
Потом начинаются заморочки. Перл с юникодом странно работает, он может получать юникод, но не подозревать об этом если у строки не проставлен флаг, что это юникод. Т.е. в реальности надо постоянно заботится во всех слоях между которыми идет обмен данными — web, db, perl, regexp, file i/o, stdin, stdout… Это не смертельно, но иногда злит.
>mod_perl дает намного больше возможностей нежели mod_php.
А так ли нужны возможности в угоду сложности?
Для типичного современного приложения типа «моя самописная CMS на shared hosting» скорее всего ничего не нужно, кроме быстрой запускалки.
Для чего-то более серьезного в mod_perl уже есть некоторые вкусности, которых нет ни в каких mod_[php|python|wsgi|passenger]. Фактически, mod_perl это набор хуков которые можно вызвать практически на любом этапе обработки HTTP-запроса Apacheм. Можно легко организовать роутинг запросов, доступ к пост-фильтрам Apache, обработку ошибок, отсылку файлов через sendfile и т.д.
не секрет, что благодаря ему php скрипты под apache работают шустрее чем скрипты на perl.
Можно ли увидеть ссылку на тесты? Или вы сравниваете mod_php с plain CGI?
>В качестве тупой запускалки по типу mod_php сейчас есть mod_perlite и он уже может исполнять Movable Type.
Ему уже года три-четыре им по очереди занимается то один то другой энтузиаст и этот проект все-ещё в стадии вау-проекта. Типа, вау! Он вроде-бы смог запустить Movable Type!
Судя по commit-логам на github этим проектом занимается в основном один человек — Aaron Stone с ноября 2007-го года, когда им была создана в svn версия 0.01. Впрочем, проект действительно сырой, у меня оно падает в корку уже при старте Apache.
Как альтернативу можно еще посмотреть на Plack и mod_psgi (аналог mod_wsgi)
Как пример — куча модулей, включая TemplateToolkit не знают, что есть на свете юникод, особенно это затрагивает чтение-запись в файлы. Поэтому приходилось либо искать по мейллистам плагины (tt2) либо переписывать модули.
Простите, но судя по Changes от Tempalate Toolkit он уже 5 лет начиная с версии 2.14 поддерживает Unicode и умеет делать как минимум вот так:
$tt->process($in, $vars, $out, binmode => ':utf8');
Потом начинаются заморочки. Перл с юникодом странно работает, он может получать юникод, но не подозревать об этом если у строки не проставлен флаг, что это юникод.
Если вы прошляпили и не сделали где надо decode — то да, огребете.
Т.е. в реальности надо постоянно заботится во всех слоях между которыми идет обмен данными — web, db, perl, regexp, file i/o, stdin, stdout… Это не смертельно, но иногда злит.
Урежте осетра. Следить надо только за тем, что входит и выходит из одного слоя — perl, поскольку только на этой границе имеет значение utf8 флаг. При этом очень интересно, как вы собрались обмениваться данными, например, между web и db, минуя perl? Или как у вас regexp оказался отдельным слоем? А stdin, stdout и file i/o — разными сущностями (да и web в случае plain CGI тоже наполовину обычный file i/o).
В реальности, в Unicode приложении вам нужно сделать decode при разборе CGI параметров, сказать sql driver'у чтобы он выставлял utf8 входящим данным (если в базе у вас UTF8), проставить нужный encoding на каждый open файла и сделать encode при выдаче HTTP body и это все.
> Можно ли увидеть ссылку на тесты? Или вы сравниваете mod_php с plain CGI?
Именно, других вариантов ведь нет? Либо завязывать приложение на mod_perl, либо завидовать наличию mod_php
> Можно легко организовать роутинг запросов, доступ к пост-фильтрам Apache, обработку ошибок, отсылку файлов через sendfile и т.д.
Это далеко не всегда нужно.
> $tt->process($in, $vars, $out, binmode => ':utf8');
Именно так я его и использую, и в свое время я не нашел этого в документации к tt2. Был озадачен, потому-что в документации есть лишь про my $template = Template->new({ ENCODING => 'utf8' }); которое без указания binmode не шибко работает.
> Если вы прошляпили и не сделали где надо decode — то да, огребете.
В перле надо везде следить за юникодом, где есть ввод-вывод. А данные могут из БД попасть в перл, пройти через пару модулей, через регекспы и выйти в виде кракоябр через JSON::Any. Ищи потом свищи, где проблема.
>Урежте осетра.
Простите, что сделать?
> Или как у вас regexp оказался отдельным слоем?
Вот например linuxforum.ru/index.php?s=7ddd94c1171d58bf01c0f7363571055d&showtopic=51252&st=0&p=504768&#entry504768 или вот web.opennet.ru/openforum/vsluhforumID9/8150.html
Проблема решается, но начинающего может ввести в легкий ступор. Или как было сказано в камментах на опеннете — «А вообще работа с юникодом в перле(да и в большинстве других языков) это шаманство, особенно когда много _различных_ потоков ввода/вывода» (с)
Именно, других вариантов ведь нет? Либо завязывать приложение на mod_perl, либо завидовать наличию mod_php
> Можно легко организовать роутинг запросов, доступ к пост-фильтрам Apache, обработку ошибок, отсылку файлов через sendfile и т.д.
Это далеко не всегда нужно.
> $tt->process($in, $vars, $out, binmode => ':utf8');
Именно так я его и использую, и в свое время я не нашел этого в документации к tt2. Был озадачен, потому-что в документации есть лишь про my $template = Template->new({ ENCODING => 'utf8' }); которое без указания binmode не шибко работает.
> Если вы прошляпили и не сделали где надо decode — то да, огребете.
В перле надо везде следить за юникодом, где есть ввод-вывод. А данные могут из БД попасть в перл, пройти через пару модулей, через регекспы и выйти в виде кракоябр через JSON::Any. Ищи потом свищи, где проблема.
>Урежте осетра.
Простите, что сделать?
> Или как у вас regexp оказался отдельным слоем?
Вот например linuxforum.ru/index.php?s=7ddd94c1171d58bf01c0f7363571055d&showtopic=51252&st=0&p=504768&#entry504768 или вот web.opennet.ru/openforum/vsluhforumID9/8150.html
Проблема решается, но начинающего может ввести в легкий ступор. Или как было сказано в камментах на опеннете — «А вообще работа с юникодом в перле(да и в большинстве других языков) это шаманство, особенно когда много _различных_ потоков ввода/вывода» (с)
Именно, других вариантов ведь нет? Либо завязывать приложение на mod_perl, либо завидовать наличию mod_php
Ничто не мешает использовать минимальные возможности mod_perl и не завязываться только на него одного. Если самостоятельно реализовать не получается — можно использовать веб-фреймворки, в CGI::Application и Catalyst поддержка CGI, mod_perl и FastCGI идет из коробки. Если не хочется фреймворк — то можно использовать Plack — это middleware, дающий единый API для web приложения и взаимодействующий с mod_perl, mod_psgi, plain CGI, FastCGI и т.д.
В перле надо везде следить за юникодом, где есть ввод-вывод. А данные могут из БД попасть в перл, пройти через пару модулей, через регекспы и выйти в виде кракоябр через JSON::Any. Ищи потом свищи, где проблема.
В драйвере БД (mysql, Pg) достаточно включить всего один флаг при коннекте, чтобы все данные шли с utf8 флагом, я уже писал выше.
> Урежте осетра.
Простите, что сделать?
Это идиоматическое выражение, которое означает, что вы преувеличиваете количество сущностей за которыми надо следить для поддержки Unicode, как тот рыбак преувеличивает размер пойманого им осетра.
> Или как у вас regexp оказался отдельным слоем?
Вот например linuxforum.ru/index.php?s=7ddd94c1171d58bf01c0f7363571055d&showtopic=51252&st=0&p=504768&#entry504768 или вот web.opennet.ru/openforum/vsluhforumID9/8150.html
Проблема решается, но начинающего может ввести в легкий ступор.
В обоих случаях проблема была в отсутствии decode на входящих данных. На regexp она у них просто проявилась, как проявилась бы и на обычном 'eq'.
Или как было сказано в камментах на опеннете — «А вообще работа с юникодом в перле(да и в большинстве других языков) это шаманство, особенно когда много _различных_ потоков ввода/вывода» (с)
Шаманством это выглядит потому что говорящий, судя по его советам, сам слабо понимает как работать с Unicode в Perl. Я еще раз повторю — для нормальной поддержки Unicode необходимо и достаточно делать decode() на входе и encode() на выходе — и это все (см. perlunitut). Все остальное (см. perlunifaq) — по большому счету syntax sugar. В приведенной проблеме на opennet все начало правильно читаться и обрабатываться после добавления «use utf8;» и «use open ':encoding(utf8)';». Первое нужно потому, что строковые константы в исходнике — это тоже ввод и Perl'у нужно сообщить о том, что они в UTF-8. Второе включило автоматическое decode/encode в utf-8 для файлов открытых через open(). В данном случае правильнее (поскольку локаль в UTF-8) было бы заменить «use open ':encoding(utf8)';» на «use open ':locale';» и тогда бы у них заработали и STDOUT/STDIN/STDERR. Но товарищи пошли по пути использования непосредственного decode/encode, что было бы OK, если бы они использовали функции из модуля Encode. В данном случае они используют функций utf8::encode/utf8::decode, которые во-первых меняют строки in place, что чревато граблями, во-вторых, в случае смены локали данный код нужно будет менять на использование функций из Encode.
И хотите совет? Не читайте opennet, ни до обеда, ни после. Большинство советчиков там именно что шаманы, которые исповедуют Cargo Cult.
И что? :)
это значит что узнать что делает perl программа возможно только запустив её
Отсутствие вменяемых IDE (О, Intellij IDEA!), вот что. Возможность решать задачу более чем сотней способов так-же не помогают кодировать большие проекты.
Возможность решать задачу более чем сотней способов не мешает кодировать большие проекты. Моя IDE это обычная unix-like система.
У вас есть метод, вы изменили его наименование. Как вы решаете задачу обновления вызова этого метода во всех проектных файлах, где он используется?
Труднее всего отвечать на вопросы с очевидным ответом :(
Через командную строку меняю содержимое файлов. Код хранится на удаленном сервере в далекой стране. В некоторых случаях удобно руками — в практике редко случались масштабные замены при рефакторингах.
Через командную строку меняю содержимое файлов. Код хранится на удаленном сервере в далекой стране. В некоторых случаях удобно руками — в практике редко случались масштабные замены при рефакторингах.
Прям через командную строку со 100% гарантией успеха? Можно пример волшебной строки, которая сможет различить какой-нибудь общий метод «execute» у двух объектов разных классов?
Ни в одном языке программирования ни одна IDE не даст 100% гарантии правильной автоматической коррекции сигнатуры метода.
Посмотрите, как это сделано в IDEA, очень здорово.
Что сдорово сделано, 100% гарантия?
*здорово, простите.
единичные ошибки (лично я сталкивался всего один раз, да и то это была операция посложнее rename) в данном случае легко поймает компилятор, не?
Примерно так, я пока не сталкивался с ошибками при рефакторинге, поэтому склонен считать, что строгая типизация это скорее благо =)
То есть холливар из темы perl vs что-то там явно перетекате в плоскость динамическая vs статическая типизация?
Скажу, что мой коллега-администратор по совместительству системный интегратор(что обязывает к написанию скриптов по деплойменту, о чём все перлкодеры так самозабвенно распинаются) пишет эти скрипты на bash, а не отнюдь на перле, для того, чтобы через неделю или месяц эти скрипты мог понять он сам, а после него ещё хоть кто-нибудь.
Комментарии ниже по ветке говорящие о том, что рефакторинг в перле всё-таки есть не дают плюсов к моей или чей-либо ещё способности понимать этот код, а также не дают каких-либо способов проверить программу на перл на наличие классических ошибок.
Только не нужно говорить мне, что я плохой программист, потому что я допускаю ошибки. Я считаю себя хорошим программистом, потому что знаю, что допускаю и буду допускать ошибки.
Также код на перл хоть и быстр, но чаще всего не приносит какой-либо пользы неперл-программистам, т.к. обычно он настолько «выразителен», что в нём нельзя разобраться не имея пятилетнего бэкграунада программирования на перл.
Комментарии ниже по ветке говорящие о том, что рефакторинг в перле всё-таки есть не дают плюсов к моей или чей-либо ещё способности понимать этот код, а также не дают каких-либо способов проверить программу на перл на наличие классических ошибок.
Только не нужно говорить мне, что я плохой программист, потому что я допускаю ошибки. Я считаю себя хорошим программистом, потому что знаю, что допускаю и буду допускать ошибки.
Также код на перл хоть и быстр, но чаще всего не приносит какой-либо пользы неперл-программистам, т.к. обычно он настолько «выразителен», что в нём нельзя разобраться не имея пятилетнего бэкграунада программирования на перл.
Есть модуль Devel::Refactor который умеет rename_subroutine. Этот модуль может использоваться из EPIC плугина для eclipse. Можно наверное и из vim'а, но у меня лично особой необходимости в таких средствах не возникало, хватало search/replace в vim и grep/sed в особо тяжелых случаях.
Извините, но EPIC, судя по его докуам умеет только «extract_subroutine», rename он уже не умеет. Это сложно назвать поддержкой рефакторинга кода. Как и возня с search-replace средствами по всему дереву проекта.
Чем мне нравится Java, так это тем, что очень легко искать в проекте места испорченные корявым рефакторингом. И ещё проще код рефакторить. В Perl это далеко не так, в нем можно играючи поиметь кучу геморроя на пустом месте.
Чем мне нравится Java, так это тем, что очень легко искать в проекте места испорченные корявым рефакторингом. И ещё проще код рефакторить. В Perl это далеко не так, в нем можно играючи поиметь кучу геморроя на пустом месте.
Извините, но EPIC, судя по его докуам умеет только «extract_subroutine», rename он уже не умеет. Это сложно назвать поддержкой рефакторинга кода.
Я могу предположить что в Java 'rename function' более востребована, поскольку там очень любят растаскивать код на однострочные методы (видимо сказывается легкая доступность 'Extract Method' ;) ), соответственно методов становится много, по названиям они путаются и приходится часто их переименовывать. В Perl такие однострочные функции я наблюдаю обычно в финансовых расчетах, где нужны и промежуточные результаты и итог одновременно и тут действительно часто возникают функции под названием вроде calc_percent, calc_percent_more, которые нужно переименовывать в более приличный вид, но такого, чтобы это потребовало серьезной автоматизации — не встречал. По большому же счету я затрудняюсь называть чисто косметический rename function — рефакторингом.
Как и возня с search-replace средствами по всему дереву проекта.
Если вызовы размазаны по всему дереву проекта — то это уже code smell или какой-то низкоуровневый API. В большинстве случаев некий метод вызывается единицы раз.
Чем мне нравится Java, так это тем, что очень легко искать в проекте места испорченные корявым рефакторингом. И ещё проще код рефакторить. В Perl это далеко не так, в нем можно играючи поиметь кучу геморроя на пустом месте.
Кучу геморроя вы поймаете в любом языке как только попробуете поменять какой-нибудь низкоуровневый API приложения и сделать следующий шаг после применения 'Add Argument' к методу — изменению фактических аргументов, которые передаются методу. Все закончится тем же ручным search-replace по всему дереву, который особо не автоматизируется из-за того что каждый случай использования метода надо анализировать чтобы понять какие параметры использовать и откуда их брать в данном контексте. При этом надо понимать что на практике этот search/replace является всего-лишь разовым механическим действием, которому предшествует намного более долговременная разработка и тестирование этого нового API (если по Fowler'у, то 'Substitute Algorithm' ).
>По большому же счету я затрудняюсь называть чисто косметический rename function — рефакторингом.
Об чем и речь. Остается лишь find/replace.
>Если вызовы размазаны по всему дереву проекта — то это уже code smell или какой-то низкоуровневый API. В большинстве случаев некий метод вызывается единицы раз.
Всякое бывает, особенно в унаследованном коде.
>Кучу геморроя вы поймаете в любом языке как только попробуете поменять какой-нибудь низкоуровневый API приложения и сделать следующий шаг после применения 'Add Argument' к методу
В IDEA я по крайней мере быстро выявлю все проблемные места. В популярных IDE для Perl (коих две) вроде бы нет даже примитивного «find usage»?
Об чем и речь. Остается лишь find/replace.
>Если вызовы размазаны по всему дереву проекта — то это уже code smell или какой-то низкоуровневый API. В большинстве случаев некий метод вызывается единицы раз.
Всякое бывает, особенно в унаследованном коде.
>Кучу геморроя вы поймаете в любом языке как только попробуете поменять какой-нибудь низкоуровневый API приложения и сделать следующий шаг после применения 'Add Argument' к методу
В IDEA я по крайней мере быстро выявлю все проблемные места. В популярных IDE для Perl (коих две) вроде бы нет даже примитивного «find usage»?
>По большому же счету я затрудняюсь называть чисто косметический rename function — рефакторингом.
Об чем и речь. Остается лишь find/replace.
Я не очень улавливаю о чем собственно у вас речь. У меня складывается впечатление что ваш мессадж в том, что рефакторинг с применением некошерного find/replace — это и не рефакторинг вовсе?
>Кучу геморроя вы поймаете в любом языке как только попробуете поменять какой-нибудь низкоуровневый API приложения и сделать следующий шаг после применения 'Add Argument' к методу
В IDEA я по крайней мере быстро выявлю все проблемные места.
Быстро — не выявите, если проблемными являются, в зависимости от контекста, только 10 из 100 мест, где используется данный method.
В популярных IDE для Perl (коих две) вроде бы нет даже примитивного «find usage»?
grep/ack прекрасно работает в качестве «find usage».
Komodo — не то что вменяемая, а прекрасная IDE. И она присутствуте и помогает разрабатывать большие проекты.
vim :)
Кстати я лично на Windows использую Strawberry Perl — как-то поприятнее и инсталл, и работа с модулями :)
я пишу только на интерпритаторах (ruby, php, python, javascript, scala) и вот недавно хотел заполнить недостающий элемент — perl. И знаете, через неделю передумал.
А по поводу плюсов перла —
>Программы, написанные на Perl (как и в случае с любым другим скриптовым языком), одинаково хорошо работают под разными операционными системами.
Нуну. Java тоже имеет JVM под каждую ОС, и ANSI C++ тоже имеет компилятор под каждую ос, не удивляет.
>Зачастую то, что на другом языке программирования (например, PHP) занимает десять строк кода может быть написано на Perl в одну строчку.
о_О На руби вообще наверно в две буквы? (p «helloworld» например)
>Если перед вами стоит какая-то задача, загляните в CPAN. Скорее всего, кто-то уже решил ее. Вам остается лишь скачать модуль и прочитать документацию к нему.
Ruby — gem'ы, PHP — PEAR, phpclasses, google, etc. А под javascript вообще дикое количество фрэймворков.
Неа, буду ждать перл6, потом годик понаблюдаем, потом посмотрим, закапывать или нет =)
А по поводу плюсов перла —
>Программы, написанные на Perl (как и в случае с любым другим скриптовым языком), одинаково хорошо работают под разными операционными системами.
Нуну. Java тоже имеет JVM под каждую ОС, и ANSI C++ тоже имеет компилятор под каждую ос, не удивляет.
>Зачастую то, что на другом языке программирования (например, PHP) занимает десять строк кода может быть написано на Perl в одну строчку.
о_О На руби вообще наверно в две буквы? (p «helloworld» например)
>Если перед вами стоит какая-то задача, загляните в CPAN. Скорее всего, кто-то уже решил ее. Вам остается лишь скачать модуль и прочитать документацию к нему.
Ruby — gem'ы, PHP — PEAR, phpclasses, google, etc. А под javascript вообще дикое количество фрэймворков.
Неа, буду ждать перл6, потом годик понаблюдаем, потом посмотрим, закапывать или нет =)
Если осилить структуры данных в перле и несколько его фирменных штучек, то окажется, что perl довольно таки чист, примитивен и прост в использовании.
PEAR, phpclasses, google вы сравнили с единой системой загрузки, установки, тестирования и документации модулей CPAN? ну-ну
Chikey — я знаю почему вы передумали. О ваших проектах на php я много чего знаю (как они написаны), и могу сказать что вам еще учиться и учиться — чтобы хорошо начать писать хотя бы на PHP, не говоря уже о том что вы перечислили в скобках. Ну и за perl — рановато, видимо…
Моё мнение (писал на Perl 2 года):
Ruby умеет всё то, что умеет Perl, но выразительнее и без ужасов с $@%!
Администраторы потихоньку переходят тоже на Ruby (Capistrano, Chef etc.).
Ruby — это настоящий Perl 7 :)
Ruby умеет всё то, что умеет Perl, но выразительнее и без ужасов с $@%!
Администраторы потихоньку переходят тоже на Ruby (Capistrano, Chef etc.).
Ruby — это настоящий Perl 7 :)
Update: я тут написал небольшой пост об основах программирования на Perl, может кому-нибудь пригодится: http://eax.me/perl-basics/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Mini-FAQ по Perl (Частые вопросы, ЧаВо)