LINUX.ORG.RU

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


0

0

JT Смит, президент Plain Black, создатель WebGUI, и однин из незамеченных, но успешно использующих Perl в бизнесе, недавно послал мне это эссе. Он дал мне(O'Reilly) разрешение издать это полностью здесь.

Каждый день, я задумываюсь о том, почему я пишу на Perl а не на PHP, Java, C#, Ruby, Python, или [подставте ваш любимый язык сюда]? Люди говорят что, "Perl не используется больше" или, "Рубин - рулез..."

Есть миллионы программистов Perl во всем мире. Perl 5 активно поддерживается, и Perl 6 находится в развитии. Больше чем 3000 Модулей Perl были выпущены в 2006г, и вдвое больше должны быть выпущены в этом году. Действительность состоит в том, что Perl является совсем не мертвым.

>>> Взято с сайта =>



Проверено: Shaman007 ()

Ответ на: Re: Perl мертв. Долгой жизни Perl... от vadiml

Re: Perl мертв. Долгой жизни Perl...

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

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

sv75 ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от vadiml

Re: Perl мертв. Долгой жизни Perl...

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

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

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

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

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

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

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

yk4ever ()
Ответ на: Re: Perl мертв. Да здравствует Perl! от vadiml

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

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

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

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

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

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

sv75 ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от yk4ever

Re: Perl мертв. Долгой жизни Perl...

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

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

$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 жив и живее всех живых.

allter149 ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от allter149

Re: Perl мертв. Долгой жизни Perl...

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

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

sv75 ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от yk4ever

Re: Perl мертв. Долгой жизни Perl...

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

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

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

Xellos ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от sv75

Re: Perl мертв. Долгой жизни Perl...

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

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

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

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

allter149 ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от Xellos

Re: Perl мертв. Долгой жизни Perl...

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

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

sv75 ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от allter149

Re: Perl мертв. Долгой жизни Perl...

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

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

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

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

sv75 ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от yk4ever

Re: Perl мертв. Долгой жизни Perl...

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

Ты просто не знаком с ещё большей ясностью и читабельностью. То что я могу сразу определить (в том числе и на глаз), что $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 типа скобок (), [], {} - непосильная для программиста задача.

mihalych ★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от sv75

Re: Perl мертв. Долгой жизни Perl...

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

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

$value =~ /$regexp/

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

vadiml ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от mihalych

Re: Perl мертв. Долгой жизни Perl...

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

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

sv75 ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от sv75

Re: Perl мертв. Долгой жизни Perl...

> > Я имею в виду синтаксис, а не семантику (т.е. скобки, классы, обобщённое программирование а-ля 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++...

allter149 ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от vadiml

Re: Perl мертв. Долгой жизни Perl...

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

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

sv75 ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от sv75

Re: Perl мертв. Долгой жизни Perl...

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

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

vadiml ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от allter149

Re: Perl мертв. Долгой жизни Perl...

errata:

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

allter149 ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от mihalych

Re: Perl мертв. Долгой жизни Perl...

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

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

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

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

Hjorn ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от mihalych

Re: Perl мертв. Долгой жизни Perl...

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

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

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

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

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

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

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

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

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

yk4ever ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от sv75

Re: Perl мертв. Долгой жизни Perl...

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

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

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

vadiml ★★★★★ ()

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

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

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

R_Valery ★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от vadiml

Re: Perl мертв. Долгой жизни Perl...

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

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

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

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

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

sv75 ★★★★★ ()
Ответ на: Re: Perl мертв. Да здравствует Perl! от R_Valery

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

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

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

sv75 ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от Hjorn

Re: Perl мертв. Долгой жизни Perl...

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

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

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

или:

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

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

mihalych ★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от sv75

Re: Perl мертв. Долгой жизни Perl...

> не хочу писать ($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);

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

mihalych ★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от sv75

Re: Perl мертв. Долгой жизни Perl...

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

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

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

Hjorn ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от mihalych

Re: Perl мертв. Долгой жизни Perl...

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

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

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

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

sv75 ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от mihalych

Re: Perl мертв. Долгой жизни Perl...

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

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

> или:

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

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

Hjorn ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от sv75

Re: Perl мертв. Долгой жизни Perl...

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

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

Hjorn ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от mihalych

Re: Perl мертв. Долгой жизни Perl...

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

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

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

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

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

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

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

yk4ever ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от yk4ever

Re: Perl мертв. Долгой жизни Perl...

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

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

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.

allter149 ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от allter149

Re: Perl мертв. Долгой жизни 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.

allter149 ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от allter149

Re: Perl мертв. Долгой жизни Perl...

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

allter149 ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от allter149

Re: Perl мертв. Долгой жизни Perl...

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

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

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

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

sv75 ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от sv75

Re: Perl мертв. Долгой жизни Perl...

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

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

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

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

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

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

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

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

allter149 ()
Ответ на: Re: Perl мертв. Да здравствует Perl! от anonymous

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

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

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

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

> man сарказм

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от allter149

Re: Perl мертв. Долгой жизни Perl...

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

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

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

allter149 ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от allter149

Re: Perl мертв. Долгой жизни Perl...

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

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

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

Hjorn ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от allter149

Re: Perl мертв. Долгой жизни Perl...

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

tuples

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

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

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

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

sv75 ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от Hjorn

Re: Perl мертв. Долгой жизни Perl...

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

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

allter149 ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от sv75

Re: Perl мертв. Долгой жизни Perl...

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

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

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

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

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

:-)

allter149 ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от allter149

Re: Perl мертв. Долгой жизни Perl...

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

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

sv75 ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от allter149

Re: Perl мертв. Долгой жизни Perl...

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

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

sv75 ★★★★★ ()
Ответ на: Re: Perl мертв. Долгой жизни Perl... от allter149

Re: Perl мертв. Долгой жизни Perl...

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

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

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

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

Hjorn ()

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

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

sv75 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.