Что будет, если в функцию передать не один, а ноль или два и более аргументов? Никакой проверки нет.

Да, вы, сударь, Перл не осилили:

sub echo($) { ...

...и проверка будет. Прежде чем хаять какой-нить язык, неплохо было бы его знать.

Правильнее будет: «качество кода зависит НЕ ТОЛЬКО от языка, НО И от программиста».

Сразу стало ясно с кем общаюсь. Дальше не читал.

Perl требует гибкий, быстрый и свободный от политики ум.

И силу воли, чтобы столько лет долбить окоченевший труп верблюда.

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

Стоит воспринимать это решение не как костыли, а как «вариация на тему» - есть встроенный механизм, есть альтернативы.

Аналогично с ООП: есть базовые возможности, есть множество альтернатив.

Стоит воспринимать это решение не как костыли, а как «вариация на тему» - есть встроенный механизм, есть альтернативы.

Аналогично с ООП: есть базовые возможности, есть множество альтернатив.

Им бесполезно рассказывать. Эти люди не уживаются с TIMTOWTDI и свободой выбора. Им нужно чтобы кто-то или что-то устанавливало для них правила. Без правил они теряются и пишут код от которого сами не в восторге обвияя при этому ЯП. Клиника.

Без правил получается Common Lisp. Разобщённое сообщество, где каждый по сути маргинал, потому что нет единых установленных правил. Вива анархия!

Да, Perl умеет быть лаконичным, но, увы, обычно в ущерб ясности и предсказуемости.

Для ясности - пиши на паскаль, для предсказуемости - на асме. Перл НЕ ДЕЛАЛСЯ для школоло, это язык для профи. После «погружения» в язык все эти $#@ покажутся предельно ясными.

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

Дебажить это — кошмар.

Отнюдь, не сложнее АСП или Пестона - print - наше всё. :) В Перле нет вычурностей, каждую вещь можно тыкнуть и сказать что это.

Потом, надо знать, что shift — это не переменная, а функция

см. выше про сипиписников.

... но, спрашивается, на хрена эти витиеватости

Потому что Перл - это вам не Васик, который вы освоили по методичке, ещё раз - это язык ПРОФИ. Соотв. и возможности должны быть профессиональные. Тот же @_ внутри функции не просто ТУПО принимает аргументы, но может этими аргументами наполняться прямо внутри функции! Динамика Перла - это и есть ради чего вообще имеет смысл связываться с миром «не статики»:

bzbz();
bzbz('get off!');

sub bzbz($)
{
    unshift(@_, 'def param') unless scalar(@_);
    
    print "You said: ". shift ."\n";
}

You said: def param
You said: get off!

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

Есть объективная сложность языка, которую синтаксисом не замаскировать. Если язык для вас очень сложный, возьмите «ЛОГО» - в нём всё просто и очевидно. :) В Перл нельзя придти после недельных курсов программирования, до него тоже надо дорасти (как до кватернионов в математике).

ООП в perl5 — просто боль.

:))) Вот тут вы вообще не правы. Если угодно, модель Перла чуть ли не повторяет СМОЛЛТОК! А последний - это вообще бог, отец и классика ООП. Да, несколько вычурнее того, к чему привыкли жабоклепатели, но зато на порядок мощнее. Одна только смена предка чего стоит!

Реальная бизнес-логика тонет в этой каше.

Не надо этой кулинарии! Каша - она ТОЛЬКО В ГОЛОВАХ. Ни один язык не спасёт, если ты накидал в кучу классов, не понимая архитектурных принципов.

При том, что я сторонник очень осторожного использования ООП только при явной необходимости, совсем-то без него тоже нельзя.

Вот за это вам сразу минус 2 балла. ООП не бывает «чуть-чуть», либо ты проектируешь полноценную ООП систему, либо пиши на «плоских» языках. Не удивительно, если «чуть-чуть ООПшная» программа на Перл получится перловой кашей! :)

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

Для ясности - пиши на паскаль, для предсказуемости - на асме.

А можно просто взять Python, Ruby, CoffeeScript/LiveScript или $that_slick_modern_language_of_your_choice, совмещающие оба параметра.

Перл НЕ ДЕЛАЛСЯ для школоло, это язык для профи. После «погружения» в язык все эти $#@ покажутся предельно ясными.

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

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

Это к чему здесь?

> Дебажить это — кошмар.
Отнюдь, не сложнее АСП или Пестона - print - наше всё. :) В Перле нет вычурностей, каждую вещь можно тыкнуть и сказать что это.

Речь шла о том, что слишком много нештатных ситуаций обрабатывается интерпретатором в режиме «черт знает, что он имел в виду, попробуем так». Как известно, failing early — очень важная стратегия, позволяющая избегать неприятных сюрпризов где-нибудь на продакшене. Так вот, если Питон при любом удобном случае кидает исключение (чем дико бесит поначалу, но приучает яснее формулировать мысли), то добрый Перл всё-всё прощает и в результате по умолчанию тащит ошибку дальше и дальше, что может привести к тихому накоплению ошибок в данных и выходу проблемы уже на принципиально иной уровень. Соответственно, опытный программист будет всеми возможными способами проверять входные данные (и не принтом, а хотя бы через assertions). Увы, на Перле это означает чрезмерное раздувание тела программы.

> ... но, спрашивается, на хрена эти витиеватости
Потому что Перл - это вам не Васик, который вы освоили по методичке, ещё раз - это язык ПРОФИ. Соотв. и возможности должны быть профессиональные. Тот же @_ внутри функции не просто ТУПО принимает аргументы, но может этими аргументами наполняться прямо внутри функции! [...]

Отлично. Внимание, вопрос: ЗАЧЕМ?

Приведенный многострочный пример транслируется в Питон так:

def bzbz(msg='def param'):
    print 'You said: ' + msg

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

> Сам язык должен способствовать чистоте и ясности текста.
Есть объективная сложность языка, которую синтаксисом не замаскировать. Если язык для вас очень сложный, возьмите «ЛОГО» - в нём всё просто и очевидно. :) В Перл нельзя придти после недельных курсов программирования, до него тоже надо дорасти (как до кватернионов в математике).

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

> ООП в perl5 — просто боль.
:))) Вот тут вы вообще не правы. Если угодно, модель Перла чуть ли не повторяет СМОЛЛТОК! А последний - это вообще бог, отец и классика ООП. Да, несколько вычурнее того, к чему привыкли жабоклепатели, но зато на порядок мощнее. Одна только смена предка чего стоит!

И чего она стоит? И, самое главное, какая разница, кто там бог и отец, когда есть задача и надо ее решить как можно проще и изящнее?

> Реальная бизнес-логика тонет в этой каше.
Не надо этой кулинарии! Каша - она ТОЛЬКО В ГОЛОВАХ. Ни один язык не спасёт, если ты накидал в кучу классов, не понимая архитектурных принципов.

Чистый и грязный синтаксис — одно. Понимание архитектуры — другое. Смешение этих понятий = каша в голове. Поздравляю.

> [...] очень осторожного использования ООП только при явной необходимости [...]
ООП не бывает «чуть-чуть», либо ты проектируешь полноценную ООП систему, либо пиши на «плоских» языках. Не удивительно, если «чуть-чуть ООПшная» программа на Перл получится перловой кашей! :)

То есть, на одном языке надо использовать только ООП, а на другом ООП использовать нельзя никогда? Некоторые части системы прекрасно живут в виде функций, сгруппированных в модули. Другие части явно требуют создания классов. В первом случае лишняя сложность появляется от ООП, во втором — от его отсутствия.

sub echo($) {say $_[0]}

Похоже, `say` появился в 5.10, так что я его уже не застал.

`($)` не помню; действительно, это решает проблему контроля кол-ва аргументов. Тем не менее, остается проблема читаемости: без документации такая сигнатура дает слишком мало информации о функции (если она не уровня echo и hello world), поскольку у аргумента нет ни имени, ни значения по умолчанию. Нужно смотреть в код. А в коде, соответственно, нужно вместо `$_[1]` писать `my $foo, $bar = @_; do_smth($foo); say $bar` и т.д., чтобы через пару недель понять, что там происходит. В итоге, опять же, много boilerplate на ровном месте.

sub bar {
   my $foo = shift // 'default';
   # the rest 
}

что тут сложного? но полный контроль над аргументами ф-ии

как на python сделать такое?

sub bar {
   my $foo = shift || int rand 10;
   # the rest 
}

sub bar { 
   state $i;
   my $foo = $i = shift || ++$i;
   # the rest 
}

Питон при любом удобном случае кидает исключение (чем дико бесит поначалу, но приучает яснее формулировать мысли), то добрый Перл всё-всё прощает и в результате по умолчанию тащит ошибку дальше и дальше, что может привести к тихому накоплению ошибок в данных и выходу проблемы уже на принципиально иной уровень.

В этом вы сильно ошиблись. Если и писали на Perl для продакшена, то очень давно и культура разработки была далека от нынешних стандартов платформы.

Сейчас все вменяемые программисты используют семантику strict и warnings. Можно сказать интерпретатору, что программа умрет при любой странности в реализации (фактически любой варнинг).

у большинства стереотипы суждения

Да, я на стороне большинства.

Вы так говорите, как будто «большинство» - это что-то плохое.

А меньшинства, это те, которые под радужным флагом ходят?

Все ваши нападки в сторону перла - полный треш, имхо. Строгой типизации в функциях видите ли нету (ее, кстати, по слухам, пилят), ООП не такой (если вы не поняли в perl5 его вообще нету как такого), путаетесь в @_... Это все специфика языка и не более. В других ЯП есть тоже своя специфика и там тоже есть свои япофобы. Могли бы кратко написать: перл приколен, но питон мне ближе. Разожгли только флейм.

Что будет, если в функцию передать не один, а ноль или два и более аргументов?

До просветления (читать днем и ночью, как мантру:) http://perlmonks.org/?node_id=663393

ООП в perl5 — просто боль.

use Moo;

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

Реальная бизнес-логика тонет в этой каше. При том, что я сторонник очень осторожного использования ООП только при явной необходимости, совсем-то без него тоже нельзя.

Если есть способ работать без ООП - пишите без ООП. Я не знаю правда какую вы «бизнес-логику» пишите, но при 2к+ строках (без комментов) каша будет почти в любом языке: а перл тут рулит и педалит за счет модульной модели (почти такой же как в паскале - а уж на нем написано просто тонны реальных бизнес-приложений).

Кстати, say теперь не только в шестёрке?

C 5.10 (2007 год если что) http://perldoc.perl.org/feature.html#The-'say'-feature

Сейчас все вменяемые программисты используют семантику strict и warnings. Можно сказать интерпретатору, что программа умрет при любой странности в реализации (фактически любой варнинг).

Можно и так, ибо warnings тянут за собой много :)

#!/usr/bin/perl

use strict;

sub f_crit {
  my ($test) = @_;

  local $SIG{__WARN__} = sub {
    die "fatality: $_[0]";
  };

  if ($test =~ /\w+/) { # warn undefined value
    ...
  }
}

f_crit();

$ perl -w /tmp/p1.pl
fatality: Use of uninitialized value $test in pattern match (m//) at /tmp/p1.pl line 12.
$ perl test.pl
$

Эти люди не уживаются с TIMTOWTDI и свободой выбора.

Не, не уживаются. Вы для себя пишете? Как говорят писатели «в стол»?

Хорошие примеры. Результаты вполне сравнимы.

Perl:

sub bar {
   my $foo = shift || int rand 10;
   # the rest 
}

def bar(foo=None):
    foo = foo or random.randint(0, 10)
    # the rest 

Тут Perl явно более DRY. Но в питоньей версии по сигнатуре сразу ясно, как ведет себя функция (т.е., принимает один необязательный аргумент), а в перловой — нет.

Perl:

sub bar {
   state $i;
   my $foo = $i = shift || ++$i;
   # the rest 
}

i = 0
def bar(foo=None):
    global i
    foo = i = foo or i + 1
    # the rest 

Такие обработчики крайне редко использую, предпочитаю warnings (слишком ленив - много кода приходится писать).

amix, я не фанитак не Перла, ни Питона. Но Перл знаю лучше. Лучше Питона, я имею ввиду. ;-) На Перле функцию с одним необязательным аргументом лучше писать так:

sub bar(;$) {

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

Что меня порадовало в Перле (много лет назад), так это *отличная* документация и развитая инфраструктура. На мой взгляд, перловая документация до сих пор лучше питонной.

И это тот код который в публичном доуступе. А точ творится на внутренних проектах?

Для особо упоротых - перл весь в публичном доступе. И свои высеры про читаемость и прочее оставь при себе, не смущай людей.

Не видеть очевидного - очевидный признак слива дискуссии. С чем вас и поздравляю!

Так слился то ты)

Из дистрибутивов выпилить обязательно!

Выпилить тебя из людей)))) Чушь говоришь, ты ещё bash выпилить предложи) Без перла никуда!

у большинства стереотипы суждения

Да, я на стороне большинства.

Вы так говорите, как будто «большинство» - это что-то плохое.

Кому-как.

А меньшинства, это те, которые под радужным флагом ходят?

Куда вас несет? Речь была о большинстве - то есть тупой массе которая своего мнения не имеет (а этого делать, так как вы уже отпадает от большинства) и пользуется готовыми для них стереотипами.

Вам ведь тут сильно страшно свое мнение опубликовать, верно?

Не, не уживаются. Вы для себя пишете? Как говорят писатели «в стол»?

И для себя и не только. И в чужом коде (со CPAN, к примеру) легко разбираюсь.

???

прототипы perl не для проверки параметров

sub echo($) { ...
...и проверка будет.

Использовать прототипы для проверки параметров - ошибка.

http://stackoverflow.com/questions/297034/why-are-perl-5s-function-prototypes...

Использовать прототипы для проверки параметров - ошибка.

Да что вы говорите? А мужики-то не знают...

Мне это напоминает сказки что «Паскаль предназначен для обучения программированию» (и, следовательно, непригоден для всего остального).

Не знаю, для чего предназначались прототипы в Перле, но с проверкой параметров они отлично справляются. Если программист хочет, он может проверку обойти:

&echo();

Но в подавляющем большинстве случаев прототип — это то, что надо. (Речь сейчас идёт о простых функциях, не методах.)

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