Comments 25
Начав путь в 1987 году, можно было бы завоевать лидерство к этому моменту. Но 15 лет без мажорного релиза сыграли свою роль.
>Счастливого пути!
В конце 2012 в статье про перл звучит как издевательство. Путь уже пройден.
В конце 2012 в статье про перл звучит как издевательство. Путь уже пройден.
Интересно вы такими комментариями хотите, читающих статью, направить на путь истинный?
Хотя, быть может, это и не совсем ясно из статьи, пожелание было обращено к программирующим на Perl, но не к языку.
Caiiiycuk, я это понял, за это спасибо) мой предыдущий вопрос был адресован JustLuckyGuy
Автору — если хочется клёвого ООП, то смотри Moose search.cpan.org/~doy/Moose-2.0604/lib/Moose.pm
Автору респект за статью. Отличная подача материала ;)
Спасибо, есть много чего интересного ) Освежил память
Цикл while может определять секцию continue, которая выполняется вне зависимости от того был вызван next, last или redo (т.е. выполняется всегда).
Неверно.
redo не дергает continue.
Вступление понравилось.
Господи, начав читать вступление я пережил дежавю. Это было лет 10 назад. С тех пор ничего не изменилось, а перловую анархию после ruby/python просто не хочется. Я реально не готов что-то крупное сейчас на perl писать.
Меня же от написания чего то действительно крупного удерживает во все не анархия и вседозволенность, а банальная не возможность быстрого рефакторинга ввиду отсутствия статической типизации и строгих проверок на этапе компиляции. И тут ruby/python/perl/js выглядят одинаково плохо. Пока я не научился писать код который не нужно проверять. Поэтому для меня динамические языки заняли нишу «быстрого программирования маленьких программ или сайтов».
о каких именно строгих проверках вы говорите?
Проверка существования метода на этапе компиляции. Во многих динамических языках можно вызывать любые сочетания букв как подпрограммы. Соответственно о корректности вызова я узнаю во время исполнения, а не на этапе компиляции. Поэтому простое переименование метода вдет к потенциальной опасности что то поломать (даже если вы исправляете грамматическую ошибку в имени метода).
Аналогично, любая описка ведет к появлению новой сущности в программе, вместо генерации компиляционной ошибки.
С другой стороны, динамические языки мотивируют использовать TDD. Что бы быть уверенным в своем коде его нужно максимально покрыть тестами, что хорошо. Но с другой стороны я часто делаю опечатки в коде, что снижает мою производительность, часто программа запукскается в «холостую» до первой опечатки.
Аналогично, любая описка ведет к появлению новой сущности в программе, вместо генерации компиляционной ошибки.
С другой стороны, динамические языки мотивируют использовать TDD. Что бы быть уверенным в своем коде его нужно максимально покрыть тестами, что хорошо. Но с другой стороны я часто делаю опечатки в коде, что снижает мою производительность, часто программа запукскается в «холостую» до первой опечатки.
Ну, современные IDE и системы статического анализа кода худо-бедно справляются с опечатками при банальном вызове
$object->metod(). Плюс отдельно поддерживаются глобальные (по всему проекту) переименования. Конечно, если у вас будет нечто вроде $method_name = 'me' . 'tod'; $$object->$method_name();, то внятного сообщения об ошибке не получите. Просто то, что ruby/pуthon запустит и выдаст ошибку run-time, например в Java будет просто диагностировано прямо в любой IDE.
Условно говоря, есть
def func(x)
end
И x может быть чем угодно. Я когда с Java уходил, мне тоже было сложно без этих «костылей», потом просто понял что самого когда пишу в разы меньше и та проблема не так актуальна
Условно говоря, есть
def func(x)
end
И x может быть чем угодно. Я когда с Java уходил, мне тоже было сложно без этих «костылей», потом просто понял что самого когда пишу в разы меньше и та проблема не так актуальна
Имею примерно одинаковый опыт на perl и на ruby. В ruby для web, perl — системное программирование, обработка данные (и в прошлом тоже web).
Как только долго пишу на Perl — руби видеть не хочется. Как только долго пишу на Ruby — перл видеть не хочется =)
Как только долго пишу на Perl — руби видеть не хочется. Как только долго пишу на Ruby — перл видеть не хочется =)
Теперь понятно откуда растут ноги у многих фич PHP. Спасибо, познавательно.
а еще Perl хорош тем, что несмотря на многолетний опыт программирования, из подобных статей я всегда узнаю что-то новое. вообще, шаблонное программирование на Perl — из области фантастики, imho. сам язык мотивирует к творчеству, красивым и неординарым решениям.
>Perl понимает три типа контекста: пустой (без контекста), скалярный и списковый (например, присвоение значения скалярной переменной образует скалярный контекст, а присвоение массиву или хэшу — списковый контекст).
Наверно, всё-таки не три а больше. Например, ещё есть строковый и числовой (http://perldoc.perl.org/perlop.html#Auto-increment-and-Auto-decrement)
Наверно, всё-таки не три а больше. Например, ещё есть строковый и числовой (http://perldoc.perl.org/perlop.html#Auto-increment-and-Auto-decrement)
Вот еще полезный модуль. Стараюсь постоянно им пользоваться в своих проектах.
Sign up to leave a comment.
There’s More Than One Way To Do It