Parrot, или Почему мы долго ожидаем Perl 6

>Не вижу здесь никакой лени (где тут она? в условии вывода строки, что-ли?), но если хотите

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

Ленивые вычисления здесь вот где - по правилам "нетерпеливых" вычислений мы должны были бы сначала получить _весь_ вывод someprog, а затем скормить его грепу. Думаю, не трудно представить в каких случаях такой подход будет помогать, а в каких мешать.

>Покажите здесь упомянутый Вами буфер

Нет здесь никакого буфера, читайте внимательно пост.

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

>> я действительно не разобрался с Tcl. Но для моей задачи которую я решал некоторое время назад питон подошёл лучше, т.к. оказался шустрее и гораздо удобнее для написания разного рода формул...

> "Лучше, шустрее и удобнее" - это по сравнению с чем? С Tcl, с которым ты "не разобрался"?

То что питонисты не любят тикл объясняется тем, что в их системе понятий нет знания о построении dsl-я в следствии обрезанности синтаксиса питона. Питоновский дсл-ь возможен только на уровне ассоциативных массивов и именованных параметров для методов.

Недоделанные лямбды срезали на корню целый пласт, который эффективно задействовали в Руби.

В плане DSL-я Тикль стоит даже выше Лиспа(не говоря уже о Руби). Сам язык можно дополнять осмысленными кострукциями средствами самого языка.

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

> В плане DSL-я Тикль стоит даже выше Лиспа(не говоря уже о Руби).

В плане того, что тикль средствами Лиспа делается в пол-пинка, ты просто бредишь. Модель Лиспа более фундаментальная, и не стоит так дорого в смысле ресурсов, как модель тикля.

У тикля чистый runtime metaprogramming, у Лиспа - compile time metaprogramming, что гораздо лучше.

> В плане DSL-я Тикль стоит даже выше Лиспа(не говоря уже о Руби). Сам язык можно дополнять осмысленными кострукциями средствами самого языка.

Объясни мне, убогому, как дополнить язык, скажем, осмысленной конструкцией для удобного доступа к элементам списка, а не этим ухрябищем lindex $l $n. Или будешь говорить, что это удобно и тру, и не надо ничего менять?

> Из всех перечисленных языков питон самый скучный. Он не плох и не хорош. Он скучен. Мало новизны. Когда игрался с питоном особого азарта не было.

Вам шашечки или ехать?

>В результате - в языке есть _все_.

У меня дежа-вю? PL/1?

>Мне кажется, что в команде тикла не хватает человека с хорошим знанием Руби и функциональных языков, некоторые вещи можно реализовать намного лучше, не внося изменений в ядро :).

AFAIK в 9.0 обещают много расширений в сторону функциональщины.

>Вам шашечки или ехать?

В том-то и дело, что ехать, а не "шашешки" (AKA отступы) рисовать/отслеживать/подсчитывать.

> В том-то и дело, что ехать, а не "шашешки" (AKA отступы) рисовать/отслеживать/подсчитывать.

В том-то и дело, что никто из практикующих питон-программистов отступы не рисует/отслеживает/подсчитывает. Эти действия существуют лишь в вашем воспаленном, отравленном тиклем воображении. И довольно уж брызгать на нас своими безумными фантазиями, ступайте лушче разарбатвать неземной красоты DSL'и на вашем любимом велосипеде с тремя педалями и седлом.

> В том-то и дело, что ехать, а не "шашешки" (AKA отступы) рисовать/отслеживать/подсчитывать.

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

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

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

Ну ладно, разрешите тоже поучаствовать в дискуссии. Почему то никто не упомянул, что в том же питоне по сравнению с перлом, тиклем, пхп существует такое полезное и незаменимое в системах больше среднего средство как исключения, и более того стандартная библиотека написана с использованием оных. Чем хороши эти исключения? Вам не нужно проверять каждую божью функцию, возвращает она -1 или нет. Вам нужно взять ее в try-except блок ("сперва сделай - потом извиняйся"). Но даже если вы забудете это сделать, в консоли у вас сразу же вывалится весь стек вызовов функций вплоть до вызвавшей ошибку, вы обрамляете сбоящий блок в try-except и пишете обработчик ошибки - все!! Это гораздо более интуитивнее и понятнее. Если же вы забыли проверить на -1 то еще бабушка надвое сказала, что вы сможете это так просто обнаружить. Далее - то же самое ООП. Опять же, системы размера более среднего без ООП почти немыслимы (только давайте не будем спорить). Но опять же возьмем перл. Там известно, какое там ооп. Но даже если смириться и считать, что оно есть то "->" вместо "." это изврат (а что "." занята на конкатенацию строк, из чего следует и так всем известная истина, что перл заточен на обработки текста). Вот и получается, что использовать перл на нужды кардинально отличающиеся от скриптов обработки текста и небольших административных нецелесообразно. В частности не целесообразно писать на нем ГУИ, веб-фреймворки, и прочие системы размера выше среднего (про Багзиллу и их злоключения с перлом, думаю, слыхали).

Господа, кто говорит что нужно что-то одно явно не владеет темой. Попытка переписать perl-скрипты(которые, например, распространены на хостинге) на питон обречены на провал. Да, на питоне можно писать скрипты, надо только представлять себе что это даст и что сделать на нем получится только сильно через зад. Вот вы говорите что однострочники говно. Ну напишите скрипт на питоне который будет, например, находить файлы с битыми симлинками. Вот так оно выглядит на перле в одну строчку: perl -le 'foreach(<*>){ -l && !-e && print}'

В общем при администрировании перл незаменим, bash сливает по-полной. А уже этого достаточно чтобы он имел право на существование.

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

> и незаменимое в системах больше среднего средство как исключения

Поздравляю - Вы не осилили Perl и рассказываете глупости..

Читайте вторую страницу баяна http://www.perl.com/pub/a/2002/11/14/exception.html
Так же смотрите на Fatal.pm

>Однако прикладное ПО я пишу исключительно на питоне ибо это действительно удобно т.к. есть очень удобные биндинги к разным библиотекам.

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

> Ленивые вычисления здесь вот где - по правилам "нетерпеливых" вычислений мы должны были бы сначала получить _весь_ вывод someprog, а затем скормить его грепу.

Гм. У меня другое мнение - мне так кажется что то, что я не собираю весь вывод в буфер - оно к лени никакого отношения не имеет. Grep просто не хранит данные больше того времени, которые они ему нужны, и никакой лени тут толком и нет (хранение данных это же не вызов функций). Разве что ленью можно считать то что не вызывается write() для написания строки, если строка не матчится, но это как бы by design...

Ладно, так можно далеко уйти... В любом случае - я имею сказать одно - на Perl _можно_ писать функционально/декларативно и упомянутые в теме книжка "High Order Perl" и статья "Monads in Perl" (где дан код на Haskell и его трансляция на Perl) это явно показывают с примерами и объяснениями. (Вопрос удобства отложим в сторону, по крайней мере пока). Надеюсь Вы не будете мне рассказывать что это выдумки и голоса в моей голове, а показанного на самом деле не существует?

> Нет здесь никакого буфера, читайте внимательно пост.
С вопросом про буфер - да, я затупил, не так понял написанное, прошу прощения.

> Жаль что пока число таких биндингов очень небольшое и часто их не хватает

Что за феерический бред? Биндингов вполне даже много, плюс есть ctypes (с версии 2.5 поставляется с питоном), который позволяет использовать сторонние библиотеки напрямую, без биндингов.

> Там известно, какое там ооп.

Оно там есть. А у Perl есть практически уникальная возможность - синтаксис можно создать самому.

> Но даже если смириться и считать, что оно есть то "->" вместо "." это изврат

Пошто ви тrавите C++? ;)

> Ну напишите скрипт на питоне который будет, например, находить файлы с битыми симлинками.
> Вот так оно выглядит на перле в одну строчку: perl -le 'foreach(<*>){ -l && !-e && print}'

import glob, os.path, os
for fn in glob.glob('*'):
    if os.path.islink(fn) and not os.path.exists(os.readlink(fn)):
        print fn

По читабельности дёргаем перл отлично.

Для любителей однострочности (можно не переносить у ;):

import glob as g, os.path as op, os;
print '\n'.join(fn for fn in g.glob('*') if op.islink(fn) and not op.exists(os.readlink(fn))),

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

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

> Поздравляю - Вы не осилили Perl и рассказываете глупости..

Вы правы, надо признать, что перл я действительно не осилил, ибо было это мне незачем. Хотя для интереса я с ним знакомился.
Про конструкцию типа

eval {
# code
};
if ($@) {};

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

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

sub foo { my a = shift; #..
}

думаю это куда как хуже отступов.

> А давайте вы избавите нас от религиозной пропаганды. ООП на хер не нужно, и уж тем более ООП никак не облегчает проектирование и разработку больших систем. Все, кто думает иначе - больные религиозные фанатики.

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

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

> А давайте вы избавите нас от религиозной пропаганды. ООП на хер не нужно, и уж тем более ООП никак не облегчает проектирование и разработку больших систем. Все, кто думает иначе - больные религиозные фанатики.

Да что вы говорите.. И на чем зиждется такая ваша уверенность в бесполезности ООП? Может поделитесь опытом, какую такую большую систему вы написали, да еще и без ООП? Принципиально, это конечно, возможно, но не использовать более высокоуровневые средства (ООП, исключения) при наличии таковых, по меньшей мере глупо.

> Про конструкцию типа eval { code }; if ($@) {}; слышал

Хорошо что слышали, но мало.

Я понимаю что это ужасный моветон и я сейчас нарушаю все разумные правила приличия, но по ссылке пройдите все же.

И главное - держитесь на стуле крепко, оно будет рвать шаблоны и ломать стереотипы. Вы внезапно увидите полноценный try ... catch ... otherwise ... finally со всеми положенными рюшечками. И стандартные функции после подключения "use Fatal" будут бросать исключения.

Чудеса, не правда ли?

> Принципиально, это конечно, возможно, но не использовать более высокоуровневые средства (ООП, исключения)

Гы гы гы, ООП - и в "высокоуровневые средства" угодило. Смешно. Тупенькая, на дебилов ориентированная методология отображения семантики предметной области в прокрустово ложе иерархических таксономий - это не высокий уровень. Это как на машине Тьюринга пытаться программировать, ссылаясь на её "фундаментальность".

Ржу я с фонатегов ООП, они такие смешные в своей упёртости и убеждённости!

> В остальном - таки согласен. ООП - не священная корова, а подход.

Ага, очень такой ограниченный подход. За всю свою более чем двенадцатилетнюю практику я видел только два случая, когда применение OOD и OOP было оправданным. И это были не крупные системы, а вовсе даже наоборот, весьма мелкие. В крупных ООПу вообще не место.

> Гы гы гы, ООП - и в "высокоуровневые средства" угодило. Смешно.

Так вот как вы заговорили. Вы во первых не юлите, и ответьте на поставленный вопрос: разработчиком системы какого размера и функциональности вы являлись и в ней не было при этом ООП.

А по существу. Ситуация 1. Файл (несколько файлов) с процедурами (я в школе так на паскале писал) и функциями или Ситуация 2. Та же функциональность реализованная в виде системы из абстракций (объектов, классов) с методами, а так же их взаимоотношений, отражающая картину реального мира (а точнее той его части, которая моделируется данной программой). Тут даже олигофрену очевидно, что второй подход более ВЫСОКОУРОВНЕВЫЙ. Или у вас есть что возразить?

> Ага, очень такой ограниченный подход.

Не, ну как, использовать можно, местами оно вполне удобно и практично. Главное в религию (а особенно на жабке или .net, да в паре с XML - это верная жопа энтерпрайз-класса) не возводить.

> Вы во первых не юлите, и ответьте на поставленный вопрос: разработчиком системы какого размера и функциональности вы являлись и в ней не было при этом ООП.

Например, около 300kloc на Common Lisp, 20 человек. По функциональности аналогично где-то 3000kloc на какой либо Java.

Другой проект - около 50kloc на Standard ML, 4 человека, не берусь судить, сколько сотен тысяч kloc на Java было бы, но явно много.

> Тут даже олигофрену очевидно, что второй подход более ВЫСОКОУРОВНЕВЫЙ. Или у вас есть что возразить?

Молодца! Сам себе аргумент придумал, сам его опровергаешь. А ты сравни с ТРЕТЬИМ подходом, глупый человек. Что твой первый, что второй варианты - примерно одинаково низкоуровневые в сравнении с правильным дизайном.

> Читайте вторую страницу баяна http://www.perl.com/pub/a/2002/11/14/exception.html

> Так же смотрите на Fatal.pm

Да, исключения в Перле тоже есть. Правда сделано всё как обычно через одно место. Ладно, прикручиваем костыль Error.pm - уже немного лучше. Но тут вспоминаем, что большинство библиотек про исключения ничего не знают. Достаём ещё один костыль - Fatal.pm. Вот так вооружившись двумя костылями получаем что то похожее на обработку исключений. Правда базовой иерархии исключений никакой нет и приходится перехватывать всё подряд, фильтруя регекспами сообщения об ошибках. Короче, получается любимое занятие перлистов - борьба с перловым синтаксисом. Между тем в Питоне те же самые вещи делаются легко и изящно. Странно, да?

> Вы во первых не юлите, и ответьте на поставленный вопрос: разработчиком системы какого размера и функциональности вы являлись и в ней не было при этом ООП.

Обращаю внимание, что Вы переходите на личности.

> Или у вас есть что возразить?

Да, есть. Грамотно разбитая на модули-блоки система без ООП имеет тенденцию быть меньше аналогичной с ООП. Ибо ООП проще абузится и неконтроллируемо разрастается в соответствии с религией "класс на каждый чих".

Вон, тут недавно пример был: http://99-bottles-of-beer.net/language-python-1154.html

Примерно такое же я сейчас вижу и в огромном энтерпрайз-проекте (с соответствующей ценой и понтами) на жабке, с которым мне приходится работать через SOAP для его прикрутки к нашему биллингу. Смею заверить - мало приятного. И я уверен что с функциональным или процедурным подходом и модульностью (превед UNIX-way!) такую задницу построить бы не получилось.

Да, важно - я не говорю что ООП дрянь, наоборот - это нормальная вещь. Дрянь это ООП-религия.

--
Другой анонимус.

yk4ever, убедил :). Перечитал reference manual, узнал много нового :). Терь проблем с написанием скриптов на питоне у меня не осталось :)

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

Блин, мне что теперь, лекции устраивать по Perl чтобы всяком Фомам Неверующим показывать что все есть, а чего нет - быстро делается, выкладывается и появляется?

Да, нет в Perl Python-like родного механизма исключений прямо в языке. Есть косметика, аккуратно его реализующая. А в том же Python вы черта с два что-то не предусмотренное языком сделаете нормально. На память помнится только отсутствующий case и тринарный оператор но они реализуются тривиально (хотя опять же - вот вам - косметика, а не легкость и изящность), а что-то более серьезное - попадалось, но с ходу не назову, надо смотреть-вспоминать...

> Например, около 300kloc на Common Lisp, 20 человек. По функциональности аналогично где-то 3000kloc на какой либо Java.

А нутк, лисп - это в принципе респект, но это отдельный флейм. Мы то обсуждали перл vs python. Перл в той же степени functional в которой и питон, по ООП и исключениям явно просасывает. Кроме того питон строго типизирован (хоть и динамически). Из этого совершенно справедливо заключить что python более подходит для 1) разработки довольно сложных и надежных систем; 2) командной разработки; чем перл. Хотя по этим 2 пунктам их рвут статически-типизированные языки в лице Java.

> Вон, тут недавно пример был: http://99-bottles-of-beer.net/language-python-1154.html

Нутк, во первых это же специально так написано, а во вторых вариант с перлом найдете сами =), и где проще разобраться?

>На память помнится только отсутствующий case и тринарный оператор но они реализуются тривиально

В питоне 2.5 тернарный оператор имеется >>> print 'greater' if 5>2 else 'lesser' greater

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

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

Вот сейчас ты и озвучил определение быдлокоддинга. Чего ж обижатесь когда вас быдлокодерами называют?

> Блин, мне что теперь, лекции устраивать по Perl чтобы всяком Фомам Неверующим показывать что все есть, а чего нет - быстро делается, выкладывается и появляется?

Зачем лекцию? Просто расскажи как ты разные типы ошибок обрабатываешь. Пишешь сам для них классы исключений и обертки для вызовов?

> А case делаетя через elif ибо нечего плодить лишние сущности.

Так в Perl тоже нет конструкции switch...case, зато есть по крайней мере 5 способов её эмуляции. Уж лучше бы она была...

> Руби - много нового

Ну расскажите что ли, что в руби нового, чего не было в смолтолке и лиспе задолго до него?

> все есть, а чего нет - быстро делается, выкладывается и появляется

Кстати, может заодно расскажешь как по-быстрому прикрутить формальные параметры к объявлению подпрограммы. Или они тоже не нужны?

> Зачем лекцию? Просто расскажи как ты разные типы ошибок обрабатываешь. Пишешь сам для них классы исключений и обертки для вызовов?

Так Exception::Class есть:
* Exception::Class::TCF для классов исключений.
* Exception::Class::DBI для исключений БД.
* Exception::Class::TryCatch как подсластитель.

> Так в Perl тоже нет конструкции switch...case, зато есть по крайней мере 5 способов её эмуляции. Уж лучше бы она была...

Давно есть. Как стандартный модуль, кстати, а не только CPAN. use Switch;
Можно и по-другому кучей методов, да. TIMTOWTDI как-никак.

> Кстати, может заодно расскажешь как по-быстрому прикрутить формальные параметры к объявлению подпрограммы. Или они тоже не нужны?

Sub::Signatures это то, что Вам надо. Именованные параметры, прототипы и перегрузка в одном флаконе:

sub foo($bar, $baz) {
print "$bar, $baz\n";
}

Оно?

ЗЫ. Все примеры - в документации к соответствующим модулям, CPAN к Вашим услугам.

Блин, так много слышал про jython что стал сам его народу советовать посмотреть. Наконец дошли руки до него. Лажа :(. Фактически, мертв с 2001 года. Жаль, очень жаль.

>Ну ладно, разрешите тоже поучаствовать в дискуссии. Почему то никто не упомянул, что в том же питоне по сравнению с перлом, тиклем, пхп существует такое полезное и незаменимое в системах больше среднего средство как исключения, и более того стандартная библиотека написана с использованием оных. Чем хороши эти исключения? Вам не

Про пхп для справки: http://www.php.net/manual/en/language.exceptions.php

>Шутку понял, смешно. Ну-ка, покажи нам такую программу, которой надо вводить код на Питоне прямо в stdin! :D

Простой пример. Есть демон. Ты к нему подсоединился по ssh или telnet. Как ты будешь вводить расширение этого демона через ssh/telnet на Питоне? Да ещё если терминал глупый?

KRoN73 - да не изобретай ты фигню всякую, смешно уже ...

FYI: про телнет не знаю а scp входит в ssh с первого дня :)

> Про пхп для справки: http://www.php.net/manual/en/language.exceptions.php

Юзер josephson! Ты недальновиден! Механизм эксепшнов в PHP поганый. Потому что стандартная библиотека их не кидает. Получаются два ортогональных механизма ловли ошибок, что приводит к путанице и фрустрации.

Кроме того, нет finally.

> Я раньше тоже плевался на питоновский синтаксис. Но в последнее время пришлось плотно поработать с Питоном, и оказалось что синтаксис мне нисколько не мешает.

Хорошо, что добавил "мне". Да и человек ко всему привыкнуть может, и от любых удобств откажется, если жизнь прижмёт. Тем более, что Питон - не самый худший язык. Но всё же синтаксис его на редкость убогий. Надо сказать, что Питон далеко не первый язык, который _заставляет_ разбивать код на строки определённым образом и ставить тонну индентаций (если подсчитать количество строк в блоке) вместо двух символов начала и конца блока и одного символа конца выражения.

> Жалобы на кривое форматирование при копи-пасте вообще нелепы.

Может ты тривиально не понимаешь суть проблем или хочешь закрыть на них глаза? Питон отсутствием скобок может сделать процесс написания кода невыносимым. Боишься шелохнуться и дунуть на программу. Шутка ли, любой невидимый символ в индентации - значимый, и потеря его означает потеря всей сути с невозможностью востановления (в общем случае). Язык просто заставляет писать сотни ненужных мелких функций, так как с большими блоками длиннее страницы и глубже некоевого уровня работать крайне сложно, не видно где у них начало и конец. А такое простое действие как изменинение глубины блока, добавив, например, перед ним условие и построчно исправив идентацию - просто опасно; ненароком за конец блока перейдёшь и лишнюю строку переформатируешь. Ошибиться легко, ведь у блока нет никаких видимых ограничителей. В нормальных языках от лишнего пробела информация не теряется, и легко будет позже найти и выпрямить неверную индентацию. В Питон мало того, что лишняя индентация полностью меняют смысл кода, так ещё и полностью теряется этот самый оригинальный смысл и его невозможно никак востановить. Хоть убейся, хоть полный undo делай и заново всё переформатировать начинай.

Это я рассмотрел лишь проблему написания кода. О ненаглядности бесскобочной записи, навязчивости парсера, сложнмостях дебагинга (временное добавление вывода или условий), невозможности работать с более, чем одним блоком за раз в выражении, просто невозможности использовать язык для определённых целей - я промолчу. Нужно ли добровольно себе такие грабли ставить? Мне лично не хочется.

> Нормальные редакторы легко решают эту проблему.

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

И странно, что все любители питона советуют сменить текстовый редактор. Может сразу и ОС поменять? Говорят, там ещё легче программируется.

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

Самое интересное это то, что ярые противники питоновского синтаксиса обычно обладают отменной самодисциплиной. А вот сторонники обычно таковой не обладают, и посему рады, когда язык на них с палкой покрикивает.

> Скобки - это дурацкие костыли, в которых, если разобраться, никакой надобности нет.

А если всё-таки разберёмся и поймём, что надобность в них есть, причём очень частая, ты обещаешь кричать на каждом углу, что Питон - недоязык, так же активно, как ты сейчас поливаешь его критиков?

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

В нормальных языках можно описать функцию как:

function { var = something; if (cond) { some; thing } else { other } print var }

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

Идём далее. Можно функции дать имя, а можно присвоить переменной, сделав анонимной:

func = function { blah-blah };

Можно и условно присвоить:

func = cond ? function { blah-blah } : function { bara-bu };

А можно и не присваивать такую анонимную функцию, а просто её определить inline, например подав как аргумент(ы) в вызове другой функции:

call(function { "first" }, function { "second" });

Причём я делаю такие вызовы постоянно, передавая аргументами анонимные функции, скажем sort_func, которая принимает два элемента и возвращает -1, 0 или 1, или filter_func, которая принимает один элемент и возвращает boolean.

Конечно же можно внутри функции (именной или анонимной) определить несколько других функций:

function { some things; func1 = function { ... }; func2 = function { ... }; return value }

Можно также организовать вызовы анонимных функций по цепочке:

@final_values = sort { $b <=> $a } map { $_ + 1 } grep { defined } @values;

А можно и совместить все простые технологие описанные выше в любых комбинациях.

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

Блок - это единица языка. Синтакс, позволяющий иметь лишь одну такую единицу за раз - убог до упомрачения. И я уже не говорю, что блок не должен менять своей сути, разбивают ли его на 3 строки или 5 или не разбивая, ставят ли его на 3-ий уровень индентации или на первый.

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

> Но опять же возьмем перл. Там известно, какое там ооп.

А какое там ООП? Ну, там множественная наследственность, полный полиморфизм, перегружаемые операторы, инкапсуляция, делегация. Всё с этим в порядке. Может, уважаемый назовёт какой-то более конкретный парадигм ООП и мы его рассмотрим?

Всё, что есть в Питон, есть и в Перл. Кроме того объектная модель в Perl по типу Smalltalk. Все объекты наследуют от единого суперкласса UNIVERSAL, чего нет в Питоне, там единого супоркласса нет.

Бурный поток бреда, который ты тут извергаешь в двух постах, ничего общего с реальностью не имеет.

Отступы - не проблема и никогда ими не была. Я лично активно пользуюсь и питоном и PHP. Для меня абсолютно не проблема писать код и там, и там. Только в питоне он читается куда лучше.

> А такое простое действие как изменинение глубины блока, добавив, например, перед ним условие и построчно исправив идентацию - просто опасно; ненароком за конец блока перейдёшь и лишнюю строку переформатируешь.

Если ты клинический дебил, и не видишь, до какой строки ты выделяешь текст - тебе надо лечиться и к программированию тебя подпускать низя ни к какому. Если ты пользуешься неюзабельным говном навроде vi - рекомендации точно те же.

> Самое интересное это то, что ярые противники питоновского синтаксиса обычно обладают отменной самодисциплиной.

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

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

> @final_values = sort { $b <=> $a } map { $_ + 1 } grep { defined } @values;

Бредовый какой-то код. Но это будет что-то типа

final_values = sorted(int(x)+1 for x in values if x.find('defined')>-1);

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

> Синтакс, позволяющий иметь лишь одну такую единицу за раз - убог до упомрачения.

Михалыч, ты совсем больной, да? Кто тебе мешает делать вложенные блоки в питоне? Умишка не хватает догадаться, как это делается?