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

>А страницы веба ты небось в офисном WYSIWYG пишешь. Долой уровни абстракции

Михалыч, ты с кем споришь?

>Ну ты бы спросил что ли, если не понял, что я имел в виду

Я подразумеваю, что ты спорящий говорит ровно то, что хочет сказать. Я тебя за пальцы не тянул, когда ты писал "каждая видимая '{' означает начало блока"? Не тянул. То что не каждая - очевидно любому, знакомому со строчными литералами (стрингами по твоему), перловыми регекспами и поводами использовать символ '{'. За исключением тебя. То же и про "невидимые" скобки (те, которые легко не заметить).

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

Мы обсуждаем проблему выделения блоков (которую можно разбить на проблемы выделения начала и конца блоков :). И хотел сказать, что не заметить увеличение/уменьшение отступа труднее (кроме как после большого кол-ва пустых строк), чем не заметить '{}' в произвольном месте предыдущей строки. То есть питонский синтаксис увеличивает вероятность обнаружения начала/конца блока. Возможны ложные срабатывания (изменение отступа без начала блока) и неправильная оценка кол-ва закрывшихся. В скобочном же случае количество обнаруженых скобок ничего не говорит о том, сколько блоков открылось/закрылось. Для правильной оценки нужно безошибочно разпарсить текст. Вероятность не заметить скобку сильно выше, чем изменение отступа.

>Что же никто так и не разоблачил ... слышал нападки

Очень жаль, что ты слышал нападки. Я их не писал. А про разоблачения - иди перечитай. Там всё достаточно понятно IMO. Если нет - почитай пару книжек по логике (: вот это уже "нападки" - не могу придумать иной причины непонимание тобой очевидности приведеных опровержений, кроме использования не-той логики :)

>если я скажу "никак, в общем/моём случае" или "всегда, хотя существует костыль для обхода"

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

>Прервали там, где курсор стоит. :-)

Замечательно, идём дальше. Перед отпуском/большой пьянкой/whatever правил код типа "A{B{C{D{E}F}G}H" (или фирма нарвалась на bus error, и пригласила тебя починить оставленое предшественником), услужливый вим показал тебе, что курсор прошлый раз видели возле скобки между B и C. И что ты с этим сделаешь? Где и какой блок должен быть закрыт, чтобы програмка заработала?

>Как же можно говорить, что "так же везде"

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

>Не стимулирует, а заставляет...И какому такому читающему?

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

>> И в чём проблема?

>Когда нет конца блока?

Михалыч, я ведь приводил твои слова, на которые отвечал. "Чукча не читатель, чукча писатель!"? (копирайт не мой)

В чем проблема с тем, что в этом месте может быть закрыто несколько блоков?

>ты и вправду не в состоянии понять убогости синтаксиса в котором нет явных блоков

Почему? Я очень даже осознаю его проблемы. Серьёзная проблема одна - неудобно записывать крошечные структуры, состояшие из 1-3 элементов или кодирующиеся в 1-30 символов. К счастью таких языков программирования ещё не выдумали, везде "всё держится" далеко не "исключительно на индентации", т.ч. нефиг тут ругать несуществоющий в природе язык. Остальные известные мне проблемы - либо эквивалентны аналогичным в других синтаксисах, либо тривиально обходятся на програмном уровне, либо приносят больше пользы, чем вреда.

> Михалыч, ты с кем споришь?

Спрорил с твоим бессмысленным аргументом о том, что програма обязана быть представлена тем, чем на самом деле является (отступами, очевидно).

> ты писал "каждая видимая '{' означает начало блока"? Не тянул. То что не каждая - очевидно любому, знакомому со строчными литералами (стрингами по твоему), перловыми регекспами и поводами использовать символ '{'.

Ну, если ты уж хочешь такие аргументы приводить, то будь до конца честным. В моём коде в 99% случаев пары фигурных скобок образуют блок или подобие блока (например я иногда использую q{...}, qq{...}, qr{...}, qw{...}, m{...}, s{...}{...}, впрочем часто и другие типы скобок, если так нагляднее, q[...], q(...), q<...>), и в 1% случаев фигурные скобки появляются внутри стрингов и регулярных выражений (обычно также парами, посему чаще всего проблем читаемости не возникает).

> Для правильной оценки нужно безошибочно разпарсить текст.

Почти так. В 99% моих (и не только моих) случаев парсинг не нужен, и в 1% оставшихся случаев парсинг лёгкий. И в итоге в 100% случаев получаем точное разбиение на блоки без какого-либо угадывания.

Что же видим в Питоне? Код написанный на доске или на бумаге (да и в произвольном текстовом редакторе) без линейки и кульмана разбить на блоки невозможно. И я даже не рассматриваю случаи, когда код загнут на следующие строки, и когда используются строки продолжения (после конечного символа \), и многострочные стринги, а всех таких случаев уж намного больше 1% будет.

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

> Вероятность не заметить скобку сильно выше, чем изменение отступа.

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

> Очень жаль, что ты слышал нападки. Я их не писал.

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

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

Если тебя интересует завлечь неопытных, не открывая им фундаментальных проблем языка, то я тут тебе даже союзник. Меня неопытные не особо интересуют. Для каждого программиста хорошо бы выучить Питон (как пример языка, как не надо делать), а также знание многих других языков не помешает. А если у новичка требования не велики, то и вовсе может не встретить серьёзных проблем. Я побольше об опытных программистах рассуждаю, у кого проблемы не тривиальны, и инструмент им нужен гибкий, без явных проблем.

> правил код типа "A{B{C{D{E}F}G}H", услужливый вим показал тебе, что курсор прошлый раз видели возле скобки между B и C. И что ты с этим сделаешь? Где и какой блок должен быть закрыт, чтобы програмка заработала?

Скорее всего (особенно, если индентация там соответствующая), внешний код "A{B...G}H" верен. Значит я проверил бы блок "{C{D{E}F}" и завершил бы начатое. Причём, обычно достаточно проверить лишь 2 случая, а именно "{C}{D{E}F}" и "{C{D{E}F}}". Тут малое и конечное число случаев, и задача разрешима с минимальным задействованием головы, без отвлечений. В случае Питона незавершённый код обычно и вовсе не даёт синтаксическую ошибки, ни о каком лёгком нахождении и исправлении речи быть не может.

> В чем проблема с тем, что в этом месте может быть закрыто несколько блоков?

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

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

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

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

>програма ... на самом деле является (отступами, очевидно).

Ню-ню. Конечно же на самом деле программа является большой строкой и regexp-ы с конкатенацией - самые правильные методы работы с её(программы) элементами. :) михалыч таки не читатель :)

>то будь до конца честным. В моём коде в 99% случаев

Давай ты тоже? 1% случаев _достаточен_, чтобы твои слова о "каждой скобке" были ложными. Т.ч.

>неоправданных обвинений во лжи

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

>Скорее всего (особенно, если индентация там соответствующая), внешний код "A{B...G}H" верен. Значит я проверил бы блок "{C{D{E}F}"

Писать программы, руководствуясь "скорее всего"? И в надежде, что "испортив" блоки не испортили индентацию (если она вообще была правильная, что не факт в случае "добавления временного if-а, о котором ты так переживал)? А если ты добавил условие в конце B, придётся проверять до H включительно. А если ты не добавлял новый уровень, а удалял лишний с конца, придётся также проверить начиная с A. Моя оценка - 70% перелопатить в лучшем случае. Не большой выигрыш.

>В нормальном синтаксисе в любой точке кода ... можно сказать к какому уровню она относится

Опять ложь. Можно лишь сказать, что если не добавлять скобки, добавленое отнесётся к тому же уровню. Твоими словами "в 99% случаев" то же можно сказать про питонский код - s/.../"если не изменить отступ".

А чем тебя пугает возможность находиться одновременно в конце нескольких блоков я так и не понял. Опять же, пиши pass -- и эта возможность пропадёт.

>А Гвидо ... утверждает, ... анонимных функций никак в Питоне не сделать

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

>создать массовый, а никак не гибкий и мощный язык программирования

Это да. Кому нужен haskell/lisp/пр./пр. - знают, где их искать. А для своих задач - он _достаточно_ хорош. Скриптовых языков с "{}" - более чем достаточно, но почему-то "момент" у них послабее, чем у довольно кривого, не самого гибкого и не самого мощного (это не сарказм) питона. Спроси себя, в чём причина? А она то вот она - красивый синтаксис. Во всяком случае я бросил использовать перл большей частью по этой причине - и не похоже, что я один такой.

> михалыч таки не читатель

Я просто не только читатель, но и пишу много.

> Давай ты тоже? 1% случаев _достаточен_, чтобы твои слова о "каждой скобке" были ложными.

Глупо с твоей стороны. Мы обсуждали, что нагляднее, фигурные скобки или отступы. Естественно, что я имел в виду фигурные скобки, которые не учавствуют в стринге (у тебя же редактор отмечает цветом стринг?). А ты соответственно имел в виду отступы, которые в начале логических строк, а вовсе не отступы в многострочных стрингах или в строках продолжения или в загнутых длинных строках (а этих случаев намного больше 1%). Однако ты меня обвиняешь во лжи, хоть я тебя не обвиняю в ещё большей лжи. Меня интересует главное, а не мелочи. Ты же только и делаешь, что придираешься к мелочам, закрывая глаза на реальные проблемы.

Ну это как если бы ты сказал, "я запустил аналогичный код на Питон и на Руби и получил время выполнения: 25 секунд против 58 секунд, из-за чего я делаю вывод, что Питон намного быстрее Руби". А тут приходит фанат Руби и говорит, "молодец, обманул себя и других. Я перепроверил всё и получил время выполнения 57.5 секунд. Так что всё, что ты утверждаешь полнейшая ложь". Примерно так ты себя и ведёшь.

>"неоправданных обвинений во лжи" не было - были оправданные.

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

> И то, что ты не хочешь замечать эти факты(ложности) не делает их истинными

Да не было никаких ложностей. Я рассматривал либо свои случаи (и там именно "никак невозможно"), либо общие случаи (и утверждал, что "нельзя в общем случае"). Ты же менял мои случаи на другие частные и что-то пытался этим доказать. Спасибо, конечно, за твои замечания, только на верность моих утверждений они мало влияли.

> если она вообще была правильная, что не факт в случае "добавления временного if-а, о котором ты так переживал

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

> Моя оценка - 70% перелопатить в лучшем случае. Не большой выигрыш.

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

> >В нормальном синтаксисе в любой точке кода ... можно сказать к какому уровню она относится

> Опять ложь. Можно лишь сказать, что если не добавлять скобки, добавленое отнесётся к тому же уровню.

Ну не может быть это ложью. Может ты просто не понял, о чём я говорю? Я не говорю о неполной информации, когда куска программы не видно. Я говорю о таких вербальных инструкциях как "после данного выражения/фигурной скобки (или перед данным выражением/фигурной скобкой) вставь данный код". Эта инструкция всегда определена в языках с нормальных синтаксисом, но не всегда (в общем случае - никогда) в Питоне, так как там можно вставить данный код на разные уровни индентации и это повлияет на смысл.

> Опять же, пиши pass -- и эта возможность пропадёт.

Это хорошая идея, но не лучше, чем совет использовать "#{" и "#}". Практически никто так не пишет.

>>А Гвидо ... утверждает, ... анонимных функций никак в Питоне не сделать

> Перевираешь.

Точно? А если всё же поглядеть в блог Гвидо, как я сделал перед тем как написать?

Since I find alternative syntax for statement grouping (e.g. braces or begin/end keywords) equally unacceptable, this pretty much makes a multi-line lambda an _unsolvable_ puzzle.

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

Извинения в неоправдонном обвинении во лжи будут?

> почему-то "момент" у них послабее, чем у довольно кривого, не самого гибкого и не самого мощного (это не сарказм) питона. Спроси себя, в чём причина? А она то вот она - красивый синтаксис.

А многие считают, что Visual Basic, Java, C# более популярны, чем Питон. Это наверное означает, что синтаксис у них совсем уж красивый. Смею не согласиться.

> я бросил использовать перл большей частью по этой причине

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

>Я просто не только читатель

Почему же оспариваешь предложение работать с кодом в терминах обьектов типа "выражение/оператор/..." тезисом о неприемлемости работы в терминах "строк с отступами"?

>Естественно, что я имел в виду фигурные скобки, которые не учавствуют в стринге

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

>... вовсе не отступы в многострочных стрингах или в строках продолжения или в загнутых длинных строках

А я такого упрощения не делал. Или добавлял явные оговорки. Потому и не говорил ничего о том случае, когда отступ таки изменился - там могут быть разные случаи.

>Главное, что скобочный синтаксис даёт выигрыш

Договаривай: по сравнению с питонским с _полностью_ _уничтожеными_ индентами.

>Если где-то серьёзно сглупил, всегда сам исправляюсь

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

>случаи со сжатой, но консистентной индентацией ... не мешают

Так вот она перестаёт быть консистентной в случае наличия/отсутствия лишней скобки. Поскольку мы полагаем, что человек не хотел испортить программу, несбалансированость {} есть результатом "безсознательного" действия -- там может быть всё, что угодно(а вдруг после этого индентом проехались).

>о таких вербальных инструкциях как "после данного выражения/фигурной скобки (или перед данным выражением/фигурной скобкой) вставь данный код"

Действительно не понял. Тут почти убедил. Только давай сформулируем корректно: в случае необходимости исправить программу, находясь далеко, без ни-одного знакомого с питоном помощника "на месте", без никакого терминала, но со связью, питонский синтаксис будет неудобен. Только ну его на, такой отпуск, в котором нужно _помнить_ (не начитает же он их тебе) тексты всех сопровождаемых программ, в месте, где нет возможности выслать с хотя бы наладонника diff, и при обязаности находиться в досягаемости для "звонков" и с ответственностью за ... :) Кстати, мне приходилось делать нечто подобное - на месте был "прикладник", начавший знакомиться с питоном через 3 дня после моего отъезда, правда програмку только начинали писать и терминал мог быть(но не было, т.к. лень). Когда я вернулся програмка уже вовсю работала, и работает до сих пор в почти неизменном виде:)

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

Насколько я помню, в том же хаскеле это можно сделать, не пользуясь ни одной '{}'. То есть проблема не в отступах а в _Гвидовом_ _вкусе_. Поэтому "никак" опять тебя подводит -- bus error или смена вкусов с каждым может случиться.

>Извинения в неоправдонном обвинении во лжи будут

Твой ход:) Прошлое (перед цитированым) предложение от Гвидо почитай:

>because in the end (...) I find any solution unacceptable that embeds an indentation-based block in the middle of an expression.

Что, IMHO означает примерно "ибо _я_ _нахожу_ _неприемлемым_ вставку I-B блока в середину выражения".

>Visual Basic, Java, C# более популярны, чем

Слишком много параметров отличается => трудно выделить причину. Возьми похожие продукты (ниша, происхождение, что там ещё). Есть постарше, поровнее, помощнее, погибче, и даже всё это вместе(tcl?). Не вижу причин питону быть "живее" - кроме отличного (:от других:) синтаксиса.

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

Это какие-то неправильные программисты. Должно быть несколько языков(по задачам), и в "continuous" вермени (приобретаемое).

>может ты его и не знал хорошо

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

> Конечно же на самом деле программа является большой строкой и regexp-ы с конкатенацией - самые правильные методы работы с её(программы) элементами. :) михалыч таки не читатель :)

Где я говорил, что надо с программой работать с помощью regexp? Не выдумывай. А генерировать код с помощью конкатенации - это да. Это не только удобно и часто мной используется на практике, но и все (нормальные) синтаксисы на этом основаны.

basic_expression := string | number | inline_data | lvalue = rvalue

expression := basic_expression | expression ; expression | "(" expression ")" | "if" expression "{" expression "} else {" expression "}"

Ну это я упростил, но идея, на которой основано описание всех нормальных синтаксисов, должна быть понятна. Естественно синтаксис Питона (или всё же недо-синтаксис?) таким стандартным образом описать нельзя.

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

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

> А я такого упрощения не делал. Или добавлял явные оговорки. Потому и не говорил ничего о том случае, когда отступ таки изменился - там могут быть разные случаи.

Не вижу смысла рассматривать лишь простые случаи и закрывать глаза на более интересные. Да и когда отступ не изменился тоже всё совсем не так просто, как ты описал. Может быть отогнута предыдущая длинная строка в редакторе или на бумаге, которую ты можешь принять за _новую_ строку на том же уровне. А может отступ состоять из разных невидимых символов, с табом не равным 8-и пробелам, и твоё утверждение "отступ не изменился - нет изменения уровня" будет ложным.

> Договаривай: по сравнению с питонским с _полностью_ _уничтожеными_ индентами.

Нет. С уничтоженными отступами Питон не только проиграет, но и просто не будет работоспособным. Я говорил о частично недописанном коде.

> Так вот она [индентация] перестаёт быть консистентной в случае наличия/отсутствия лишней скобки.

Ты опять используешь абсолютный язык, совсем не желая разобраться в моём реальном и частом примере. Индентация совсем не важна тут, она может помочь, но и без неё всё понятно. Ты имеешь правильную программу, ты начал писать новый блок, но тебя прервали. После того как ты возвратился, ты имеешь одну фигурную скобку, первую перед курсором (первую нестринговую; не придерайся к словам), у которой нет соответствия, у всех остальных же скобок соответствие есть. Очень просто завершить свою работу (твоя оценка в 70% неверна, просто я не стал спорить). В случае же Питона ты даже не будешь знать, что работа не завершена.

> Что, IMHO означает примерно "ибо _я_ _нахожу_ _неприемлемым_ вставку I-B блока в середину выражения".

Естественно. И как я тогда сказал, учитывая положение Гвидо в мире Питона это и означает, что "вставка отступнического блока в середину выражения неприемлима, то есть невозможна в Питоне (пока я жив и решаю; чтобы вновь не придрался к словам)".

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

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

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

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

> Питон уже близок, но не по причине синтаксиса.

А по какой тогда причине, по-твоему? :)

>генерировать код с помощью конкатенации - это да

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

>идея, на которой основано описание всех нормальных синтаксисов

точно так же выглядит в питоне - только вместо "{}" "INDENT" и "DEDENT", вставляемый парсером, и, соответственно, заменяемый на отступы "pretty printer"-ом. Да, оно требует чуть-чуть больше работы от них. Помнишь, по чём мегагерцы для народа?

>Да и когда отступ не изменился тоже всё совсем не так просто, как ты описал

Уже писал: сложнее в случае, когда разрыв строки приходится на строковую константу в месте, после :МНОГО_ПРОБЕЛОВ (или других невидимых символов, откуда они возьмутся в программе непонятно, но пусть), в случае, когда их число на новой строке равно инденту следующей. Достаточно отсутствия любого из условий и это будет заметно. Сравни вероятность с "скобочным" случаем, в котором незамеченая кавычка (а в перле почти любой пунктуационный символ) в любом месте перед '{' может изменить значение последней с "начало блока" до просто символа в строке/регекспе.

>Я говорил о частично недописанном коде.

В этом случае скобки проигрывают. Адекватное место для закрывающей скобки может быть где угодно (в том числе перед "новой" - если ты решил разбить старый блок на 2). Однако даже если ты знаешь, что не собирался сильно править структуру, тебе придётся разпарсить весь текст уровня "глубже" вставленой скобки - просто чтобы найти место потенциальной вставки недописаного конца. Случай, когда обрезаный парсер твоего редактора не будет обманут синтаксисом, считаю твоим лично везением - мне очень часто не везло. В питоне же достаточно приложить палец к "инденту" и прокрутить вниз (:или скопировать его в строку поиска, добавив [^ ] -- для тех кто умеет пользоваться редактором получше:)

>то есть невозможна в Питоне

По причине Гвидо, а не отступов. Хрен с ним с питоном - это просто "инструмент", а вовсе не "Инструмент!" (в том числе благодаря упомянутому). А за отступы пасть порву споримшы:)

> Максимум (точнее минимум - абстракции) - массив строк - который правильно "заиндентить" - 1-банановая задача

Да в том-то и дело, что бананом тут не отделаешься. Даже если ты заставишь на отдельные строки делить (чего вовсе не надо делать с нормальным синтаксисом, там можно просто манипулировать со стрингом некоего корректного выражения), то всё равно есть случаи с многострочными данными (ну, разве что эти длинные данные заставишь в одну строку составлять), или многострочными символьными строками (а уж тут не выйдет, если это тоже код, то в одну строку в Питоне нельзя, разве что заполонить всю строку таким: "\n\t\t\t"), или со строками продолжения (иль ты заставишь их в одну объединить; а как же читаемость для дебагинга?). В общем, для добавления уровня, полный парсинг надо делать в случае Питона, тут и тонны бананов может не хватить.

> точно так же выглядит в питоне - только вместо "{}" "INDENT" и "DEDENT", вставляемый парсером

А что нам с того, что парсер может однозначно распарсить некий недо-синтаксис, от этого он не получит свойств нормального синтаксиса. Ох как бы я был счастлив и не вёл бы эту дискуссию, если бы в синтаксисе Питона было бы всё, что "pretty printer", а вернее сказать "loosy filter" урезает. Ан нет, Гвидо и его любители дают мне чётко понять, что не быть мне счастливым с Питоном. Ну, нет так нет.

> Уже писал: сложнее в случае

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

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

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

> В питоне же достаточно приложить палец к "инденту" и прокрутить вниз

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

> Хрен с ним с питоном

Ну, ладно, уговорил. :)

>всё равно есть случаи с многострочными данными ...

А я буду в строку целый "statement" засовывать (то, что в перле заканчивается ';'), а блок в массив таковых. И никогда не получу "if (...) { $a=<<EOF ; что-то } else { ещё что-то ; EOF }".

>загнутая строка или строка продолжения может быть неправильно понята как новая строка на верхнем уровне

Только если следующая за ней тоже будет на верхнем уровне, а предыдущая - нет. Или если в месте "загиба" начинается одно из слов (for/if/и т.п.) и далее следует блок на 1м уровне, или очень длинный на не-первом при маленьком инденте остального кода (чтобы не заметить ненормально большого идента). Условий многовато. Хотя некоторая вероятность есть. IMO гораздо меньшая, чем неправильная интерпретация или пропуск по невнимательности незаметного символа.

>Не может оно быть где угодно

Может. Положим неправильный код: "a{bb{cc}dd{ee}ff", стоим между b и c, допустимые варианты: добавить } в любое место после первой c, а также "a{b}b{cc}dd{ee}ff" (разделяли блок после a) и "abb{cc}dd{ee}ff" (переносили условие из "после a" в "после b"). То есть всё до концавперёд и пара "родительских" блоков назад. Отсюда оценка в 70%.