Perl мертв. Да здравствует Perl!

> пожалуйста, по-подробнее об этом, где чего нельзя?

Аргументы передавать в функцию по именам. Нельзя. в Перле. (Чувствую я на пороге открытия)

> в () -- просто перечень через запятую, а [] -- это уже анонимный массив.

Эммм а чем "перечень через запятую" отличается от "анонимный массив"? И где бывают "неанонимные" массивы?

> Если так интересно, может проще в perldoc глянуть?

А где там искать-то?

> а если все же винда -- то Вас надо отправлять в игнор как тролля

Как банально. Игнор - последнее спасение проигравшего.

А что, у перла с поддержкой винды совсем задница, да?

> зачем в перле нужны эти стрёмные "->"

> стандартный способ работы со ссылкой

Во-первых с указателем, во-вторых на структуры, в третьих это чтобы не писать в C (*struct_pointer).field_name или как бы там пришлось без ->

> переменную -- как ${$link}, но для краткости {} можно опустить, если из контеста ясно что это такое, соответственно получится $$link

А, кстати вот и четвертый способ, совсем про него забыли.

> И где бывают "неанонимные" массивы?

В Перле бывают ;)

> Эммм а чем "перечень через запятую" отличается от "анонимный массив"? И где бывают "неанонимные" массивы?

Здесь имеется в виду, что

$x, $y = $y, $x;

в перле эквивалентно просто $x ( а "@list = ( $x, $y = $y, $x );" эквивалентно "@list = ( $x, $y, $x );".

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

$a, $b, list_operator $c, $d, another_list_op $e, $f

Ну и функции в перле принимают именно "перечень через запятую". В питоне семантика вызова функции немного другая, из-за того, что список (кортеж) требует отдельного литерала (скобок).

P.S. Если сделают нормальный скриптовой язык с C-подобным синтаксисом (Perl6 и JavaScript не катят), то Perl реально повторит судьбу Кобола. А пока этого не произошло, Perl жив и живее всех живых.

> Если сделают нормальный скриптовой язык с C-подобным синтаксисом

Но зачем? Основа синтаксиса С - геморой с указателями ;) настоящие пацаны в C даже не пишут a[b], только *(a + b) ;)

>Мне весьма сложно понять, зачем писать "(1,2,[3,4])" а не "[1,2,[3,4]]"

$a=[1,2,[3,4]];
@b=(1,2,[3,4]);

чем отличаются вызовы myfunc($a) и myfunc(@b)?

>> Если сделают нормальный скриптовой язык с C-подобным синтаксисом

>Но зачем? Основа синтаксиса С - геморой с указателями ;) настоящие пацаны в C даже не пишут a[b], только *(a + b) ;)

Я имею в виду синтаксис, а не семантику (т.е. скобки, классы, обобщённое программирование а-ля C++ и Java).

От указателей совсем избавиться сложно, т.к. они во многом позволяют оптимизировать разные вещи. Но вот убрать их на второй план (симулировать передачу данных сложных типов по значению) вполне можно, как показал Питон и некоторые другие скриптовые языки. Только вот реализовано это неконсистентно, как показал один из примеров в дискуссии выше, когда массив, переданный в функцию по имени "формального параметра" обращался (reverse) внутри этой функции и изменённый массив использовался снаружи вызова. :( Подобные неявности постоянно убивают в коде и заставляют днями копаться в чужом барахле. :(

> $a=[1,2,[3,4]]; 
> @b=(1,2,[3,4]); 
> чем отличаются вызовы myfunc($a) и myfunc(@b)?

Это что ли оправдание отсутствия в Перле параметров функций?

> Я имею в виду синтаксис, а не семантику (т.е. скобки, классы, обобщённое программирование а-ля C++ и Java).

Так бы и говорил - Java/C#, а то C....

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

Опять не понял. У меня в питоне что-то не симулируется паредача данных по значению, если не писать f(copy(a)), что я еще не осилил?

> Тип переменной всегда ясен из контекста.

Ты просто не знаком с ещё большей ясностью и читабельностью. То что я могу сразу определить (в том числе и на глаз), что $something это переменная, а не, скажем, функция something(), открывает море удобных возможностей. Например "inline $var expansion", или возможность записи вызова функции (или метода объекта) без скобок, если так читабельней.

> Это называется List Comprehensions

Это ты просто слово умное услышал. Мы говорили о читабельности питоновских примеров и их расширяемости. "if" и "for" в однострочных лабдах во первых совсем не интуитивны для новичка (почему именно такой порядок конструкций, что при этом первым виполняется, "if" или "for", необходимость наименования временных переменных), во вторых ограничены в возможностях (нет многострочных ламбд), и в третих _намного_ менее читабельней, чем перловые map {} grep {}.

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

Это тебе кто так сказал? Ты не стесняйся, скажи, что тебе надо сделать. И нужна ли статическая проверка или нет (переменные в динамических языках надо в run-time проверять, как завещал Smalltalk). А то много разных способов есть передать опциональные именные параметры. Для твоего обшего развития:

new LWP::UserAgent(agent => "Mozilla/Compatible", timeout => 30);

или (после use CGI):

print textfield(-name => ’age’, -default => 10);

А может так (это когда надо опциональные именные параметры перед обязательными просунуть):

print a({ href => "url", style => "bubu" }, "label");

Или опциональные именные идут после обязательных:

fetch_url("url", timeout => 40, allow_cookies => 0)

> А создание вложенных списков первращается в приключение, требующее знания двух томов мануалов.

Ну да, почитать "man perldsc" и запомнить, что делают 3 типа скобок (), [], {} - непосильная для программиста задача.

> Аргументы передавать в функцию по именам. Нельзя. в Перле.

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

$value =~ /$regexp/

хотя если содержимое $regexp храниться в явном виде, то перлу можно указать что это такое будет и он строку проанализирует при запуске

> "if" и "for" в однострочных лабдах во первых совсем не интуитивны для новичка (почему именно такой порядок конструкций, что при этом первым виполняется, "if" или "for",

Почему не очевидно, оно же очень близко к описанию множества в математике. :)

> > Я имею в виду синтаксис, а не семантику (т.е. скобки, классы, обобщённое программирование а-ля C++ и Java).

> Так бы и говорил - Java/C#, а то C....

Ну, CScript с эмуляцией всех извратов языка "C" будет только извращенец. :-) Кстати, AFAIK, в последних стандартах "C" (не K&R) сам "C" стал более "сишным", в том плане, что описание формальных параметров передачи в функцию стало более консистентным с опытом пользователей C++/Java/C# (точнее, такое описание есть наряду со стандартным K&R-ским).

Собственно, успех распространения этих языков на 80% связан с реюзом пользовательского опыта использования другого языка этой серии (и на 20% с частичной реюзабельностью, собственно, существующего кода и библиотек).

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

> Опять не понял. У меня в питоне что-то не симулируется паредача данных по значению, если не писать f(copy(a)), что я еще не осилил?

Я это и имел в виду. В Питоне (в отличии от Java), насколько я знаю, нет способа прямо в определении функции написать, что f( a ) должен значить f( copy( a ) ). Т.е. в питоне, на самом деле все работают с ссылками на объекты разного плана и не жужжат, потому что просто не знают об этом. :)

А всё идёт к тому, что сложность проектов, написанных на скриптовых языках в ближайшее время возрастёт настолько, что скриптовые языки просто обязаны будут иметь констрайнты и приведения, заимствованные из Java/C#/C++...

> можно. Но у этого есть один недостаток

Подскажи где читать (и почему этого некто не делает?)

> Это что ли оправдание отсутствия в Перле параметров функций?

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

errata:

Ну, CScript с эмуляцией всех извратов языка "C" будет _проектировать/реализовывать_ только извращенец.

> То что я могу сразу определить (в том числе и на глаз), что $something это переменная, а не, скажем, функция something(), открывает море удобных возможностей.

Но большего ты про $something ничего не можешь сказать с определённостью, если не использовать специальные правила именования. Ведь в $something может быть и простой скаляр, и ссылка на что угодно. Таким образом введение ссылок свело на нет неплохую идею с префиксами. Между тем, пример Руби показывает, что для внедрения переменных (и вообще любых выражений) в строку доллары не нужны. И скобки при вызове функций в Руби тоже не обязательны. Так что... Польза сомнительна пожалуй.

> Мы говорили о читабельности питоновских примеров и их расширяемости. "if" и "for" в однострочных лабдах во первых совсем не интуитивны для новичка

Допустим. Но ведь есть ещё filter. Почти полный аналог перловского grep, только что многострочные выражения не поддерживает. Сойдёт для новичка? ;)

> Например "inline $var expansion", или возможность записи вызова функции (или метода объекта) без скобок, если так читабельней.

Обрати свой взор на Ruby, где это достаточно эффектно реализовано и при этом не требует сиджилов к идентификаторам.

> "if" и "for" в однострочных лабдах во первых совсем не интуитивны для новичка ... и в третих _намного_ менее читабельней, чем перловые map {} grep {}.

1) Это компрехеншны, а не "лабды". Не путай.

2) Ты поразишься, но они феерически интуитивны. Насколько я видел - все их осваивают на лету.

3) В питоне есть и map, и filter. Но их выкинут в третьей версии, как раз из-за плохой читабельности.

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

> Ну да, почитать "man perldsc" и запомнить, что делают 3 типа скобок (), [], {} - непосильная для программиста задача.

Да даже если прочитать и запомнить - всё равно синтаксис чудной.

>> можно. Но у этого есть один недостаток

> Подскажи где читать (и почему этого некто не делает?)

Ларри Уолл & Co, "Программирование на Перл", стр. 310, глава Символические ссылки (книга есть в инете в формате djvu)

Господа! Вам не кажется, что хватит уж языковых войн на LOP (здесь - особенно). Грамотный программер всегда ВЫБЕРЕТ ЯЗЫК НАИБОЛЕЕ СООТВЕТСТВУЮЩИЙ ПОСТАВЛЕННОЙ ЗАДАЧЕ. И если задача подходит для реализации на нескольких языках - выбор всегда за наиболее любимым... ;-)

Эх, и почему я так не люблю С, особенно с плюсами??? :-)))

> Это что ли оправдание отсутствия в Перле параметров функций?

> что значит отсутствие параметров?

Ну чтобы были у функции сразу параметры, без @_, shift etc.

> выставить ограничение на то, что будет передаваться в функцию можно, правда этим редко пользуются.

Про ограничения знаю, не хочу писать ($a, $b, $c) = @_;

> Господа! Вам не кажется, что хватит уж языковых войн на LOP

Да ты что! Я больше узнал о ЯП из "Фразы о Лиспе", чем за время обучения институте ;)

:-)) Ну чтож, поздравляю... ;-)

В фразе ощибка, конечно. Не LOP а LOR... :-)

> Символические ссылки

А-а-а.....

> Но ведь есть ещё filter. Почти полный аналог перловского grep, только что многострочные выражения не поддерживает. Сойдёт для новичка? ;)

Так ведь сами питонисты признают его нечитаемость и хотят его выбросить из третей версии. Сравни, что более читаемо:

filter(lambda x : x > 60, map(lambda x : x ** 2, range(30)))

или:

grep { $_ > 60 } map { $_ ** 2 } (0 .. 29)

Кстати, этот синтаксис работает и в Perl 6, для тех, кто интересуется.

> Сравни, что более читаемо:

Более читаемо, конечно,

[x**2 for x in range(30) if x**2>60]

:]

> не хочу писать ($a, $b, $c) = @_;

Ну, тогда пиши так:

  %params = @_;

И все параметры доступны по именам. $params{url}, $params{name}.

Или используй %_, тогда будет тебе $_{name}, $_{age}. :)

Зато сможешь многое с этими параметрами сделать. Проверить их наличие,
или их имена, или их число, или передать их всех другой функции:

  die "Pass at least one named parameter" unless %params;
  my @passed_param_names = keys %params;
  $params{version} ||= "2.6.4";  # set the default value if not given
  function2(%params);

В общем, проблема надумана. :)

> Ну чтобы были у функции сразу параметры, без @_, shift etc.

http://search.cpan.org/~ovid/Sub-Signatures-0.21/lib/Sub/Signatures.pm

А ещё можешь почитать флейм "Parrot, или Почему мы долго ожидаем Perl 6". Там много чего интересного про Перл и не только ;)

> И все параметры доступны по именам.

Нет, спасибо, я всегда дурел с параметров-хешей :(

> Проверить их наличие, или их имена, или их число, или передать их всех другой функции:

По-моему ничто не мешало сделать и отдельный список параметров, и именованные параметры (хмм, как раз в духе перла)

> Сравни, что более читаемо:

> filter(lambda x : x > 60, map(lambda x : x ** 2, range(30)))

> или:

> grep { $_ > 60 } map { $_ ** 2 } (0 .. 29)

Не буду кривить душой: второй вариант намного приятнее :)

> По-моему ничто не мешало сделать и отдельный список параметров, и именованные параметры (хмм, как раз в духе перла)

В Perl 6 так и сделали.

> Проверить их наличие, или их имена,

А в языках с формальным списком аргументов это делается автоматически.

> или их число, или передать их всех другой функции:

А вот как это делается с нормальным синтаксисом:

def myfunc(**params):
    assert len(params), 'Pass at least one named parameter'
    params.setdefault('version', '2.6.4')
    function2(**params)

> В общем, проблема надумана. :)

Это преимущества перла, как видим, надуманны.
А недостаток налицо: из заголовка определения функции невозможно понять, что ей следует передавать.
Либо необходима дополнительная документация, либо нужно копаться в коде.

> Это преимущества перла, как видим, надуманны.
> А недостаток налицо: из заголовка определения функции невозможно понять, что ей следует передавать.
> Либо необходима дополнительная документация, либо нужно копаться в  коде.

А в Питоне не нужно? То, что в Питоне неявно используются ссылки (причём пользователей активно убеждают в обратном, т.е. выстрелить это может в любое время), означает то, что функция может в своих потрохах менять значения аргументов. И ничто, кроме внешней документации, не может сказать: меняет она фактические _АРГУМЕНТЫ_, или нет. Пример:

def f( x ):
	"""Does this function changes its argument value in the calling block?"""
	x += 12

class C:
	i = 0
	def __init__(self, init):
		self.i = init
	def __iadd__(self, other):
		self.i += other
		return self
	def __str__(self):
		return str(self.i)

simple_type_var = 30
f( simple_type_var )
print simple_type_var

complex_type_var = C(30)
f( complex_type_var )
print complex_type_var

Нетрудно убедится, что этот код выводит 2 разных числа: 30 и 42, т.е. фактически в одном случае параметр передаётся как скаляр-значение, а в другом - как скаляр-ссылка. Где по определению функции можно понять, в каком случае переданный в качестве её фактического параметра объект может измениться, а где - нет? И нафига тогда нужны эти объявления параметров - чем это лучше перлового:

sub f ( $ $ )
{ 
    my ( $x, $y ) = @_; 
    # ... 
}

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

OMG, тяжела и неказиста жизнь передающего питоновский код в форум, что бы тот не сломался. :) Вот с нормальными переводами (надеюсь, все поменял).

> Это преимущества перла, как видим, надуманны. > А недостаток налицо: из заголовка определения функции невозможно понять, что ей следует передавать. > Либо необходима дополнительная документация, либо нужно копаться в коде.

А в Питоне не нужно? То, что в Питоне неявно используются ссылки (причём пользователей активно убеждают в обратном, т.е. выстрелить это может в любое время), означает то, что функция может в своих потрохах менять значения аргументов. И ничто, кроме внешней документации, не может сказать: меняет она фактические _АРГУМЕНТЫ_, или нет. Пример:

def f( x ): """Does this function changes its argument value in the calling block?""" x += 12

class C: i = 0 def __init__(self, init): self.i = init def __iadd__(self, other): self.i += other return self def __str__(self): return str(self.i)

simple_type_var = 30 f( simple_type_var ) print simple_type_var

complex_type_var = C(30) f( complex_type_var ) print complex_type_var

Нетрудно убедится, что этот код выводит 2 разных числа: 30 и 42, т.е. фактически в одном случае параметр передаётся как скаляр-значение, а в другом - как скаляр-ссылка. Где по определению функции можно понять, в каком случае переданный в качестве её фактического параметра объект может измениться, а где - нет? И нафига тогда нужны эти объявления параметров - чем это лучше перлового:

sub f ( $ $ ) { my ( $x, $y ) = @_; # ... }

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

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

> по определению функции можно понять, в каком случае переданный в качестве её фактического параметра объект может измениться

Нигде, поскольку есть неизменяемые (muttable) объекты, а есть изменяемые. Неизменяемые не могут измениться в принципе. Так что важно это при вызове функции. Однако проблема существует, да.

> нафига тогда нужны эти объявления параметров - чем это лучше перлового:

Наличие недостатка питона не устраняет корявость параметров перла ;)

>> по определению функции можно понять, в каком случае переданный в качестве её фактического параметра объект может измениться

>Нигде, поскольку есть неизменяемые (muttable) объекты, а есть изменяемые. Неизменяемые не могут измениться в принципе. Так что важно это при вызове функции. Однако проблема существует, да.

А какие в Питоне immutable объекты, кроме численных и строк?

И чем это отличается от перловой реализации, когда есть скаляры - значения (undef, int, float и string) и ссылки (стандартных типов, вроде HASH и ARRAY и blessed)?

Зачем в этом топике сломано 14 страниц копий (spears), многие из которых были сломаны именно по поводу references и оператора "->", который в питоне просто заменили на ".", что бы скрыть реализацию от начинающих питонистов?

> > нафига тогда нужны эти объявления параметров - чем это лучше перлового:

> Наличие недостатка питона не устраняет корявость параметров перла ;)

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

> дружище, ты делаешь такие глобальные выводы по паре моих постов?

Нет, я просто спросил.

> то что я не ставлю россыпи смайлов уподобляясь поколению пепси, вызывая тем самым у его представителей чувство дискомфорта, должно меня волновать?

> man сарказм

А по-моему, man раздражение

> еще много открытий и умных слов ждут тебя на твоем пути, о юнный падаван

Гнев и разлив желчи чувствую в тебе я, анонимный мастер. На темную сторону силы тебя они приведут.

P.S. — собственно, это я и имел под необходимостью языка с C(++) стилем функций — что бы можно было задать в перечне формальных параметров способ работы с ними):

f( Type x, Type& y, const Type& z)

Боюсь только, что такой язык в ближайшее время не родится.

> sub f ( $ $ ) { my ( $x, $y ) = @_; # ... }

А теперь представь, что писатель функции вместо того чтобы положить параметры в локальные переменные, юзает их внутри функции прямиком из @_. А потом берёт и где-нибудь в глубине кода присваивает элементу @_ новое значение. И всё - результат даже хуже, чем в Питоне. Хотя так никто не делает обычно, но возможность есть.

Без комментариев и вменяемой документации везде плохо, но в Питоне всё же чуть полегче из-за его простоты и строгости. А формальные параметры - это удобно. И ничем нельзя оправдать их отсутствие. Честно говоря, не припоминаю языков кроме Перла где бы их не было.

> не припоминаю языков кроме Перла где бы их не было.

REXX... и ассемблер :)

> А какие в Питоне immutable объекты, кроме численных и строк?

tuples

> И чем это отличается от перловой реализации, когда есть скаляры - значения (undef, int, float и string) и ссылки (стандартных типов, вроде HASH и ARRAY и blessed)?

А к этому претензий и не было. Были к references.

> references и оператора "->", который в питоне просто заменили на ".", что бы скрыть реализацию от начинающих питонистов?

Это где в Питоне "." для списков и прочим?

>> sub f ( $ $ ) { my ( $x, $y ) = @_; # ... } > А теперь представь, что писатель функции вместо того чтобы положить параметры в локальные переменные, юзает их внутри функции прямиком из @_. А потом берёт и где-нибудь в глубине кода присваивает элементу @_ новое значение. И всё - результат даже хуже, чем в Питоне. Хотя так никто не делает обычно, но возможность есть.

Собственно, у меня есть функции, которые изменяют аргументы и это не так сложно. И не только я это использовал. Просто по виду определения функции ни у кого не возникает ощущения, что это действительно функция, а не произвольная подпрограмма(sub[routine]). А у человека, перешедшего с C-подобного языка на Python такое ощущение может возникнуть, к несчастью для остальных разработчиков одного и того же проекта. Получается, в Питоне также есть кривая обучения и она также в самом начале идёт вверх не так быстро, как того хотелось бы.

> Это где в Питоне "." для списков и прочим?

Неконсистентность (точнее, синтаксис/лексический анализатор заточен). В Perl6 будет и "у нас" подобные "компромиссы с общественностью" в виде:

@a[5], %h{key}, $a[5], $h{key}

вместо, соответственно: $a[5], $h{key}, $a->[5], $h->{key}

, а зря. Радуйтесь. :-(

:-)

> с C-подобного языка на Python такое ощущение может возникнуть,

Ну а если он с C# - то не возникнет. Так что это бабушка на двое сказала.

> В Perl6 будет и "у нас" подобные "компромиссы с общественностью"

Судя по этому письму в Перл6 все будет.... не очень, а никаких компромиссов в Питоне я не вижу. Там нет разделения ссылки-не ссылки. есть деление muttable/unmutttable, и ссылок на вторые не бывает, а у первых ссылки всегда.

> Собственно, у меня есть функции, которые изменяют аргументы и это не так сложно. И не только я это использовал.

Да понятно, что не сложно. Только если в документации это не описано, то может стать большим сюрпризом. Как и в примерах выше на Питоне.

> Получается, в Питоне также есть кривая обучения

Нет конечно, питоноводы знают язык с рождения. Это особый дар свыше :D

Да, довольно вяло пофлеймили что-то, даже за тысячу не вышли...

Да, куда уж нам со своими перлами до переключалки раскладок в KDE :)