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

Питон less тоже очень хорошо показывает. Даже лучше чем перл(если последний криво, хотя и синтаксически правильно, сформатировать).

Так к чему это? Пытаешься уйти от темы?

>Питон less тоже очень хорошо показывает.

"нехорошо" показывает, если строки длиннее, чем ширина терминала. И нехорошо, если вьювер не с моноширинным шрифтом.

>"нехорошо" показывает, если строки длиннее, чем ширина терминал

-S пробовал?

>если вьювер не с моноширинным шрифтом

У нас тут форум юных кулинаров? Снова лапша на уши. Размеры пробелов совпадают, и отступы отлично видны. Или ты предпочитаешь выводить каждую строку новым шрифтом? Креативно, ничего не скажешь.

>-S пробовал?

Это которая "a long line that does not fit in the screen width is not shown."?:)

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

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

> Мы же не о питоне спорим.

А о чем? Именно о том, что это один из самых неудобных языков, невероятно сложный для простого дебагинга. Невозможно даже вставить "print something if DEBUG_MODE;" между коммандами (на отдельной строке или посреди строки) без того, что бы пробелами (логичнее табами) не указать к какому уровню оно отностися.

Я уже не говорю о чем-то более сложном, что временно ставится в первый столбик (дабы видно было, что не часть программы):

if ($debug) {

...

}

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

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

>А о чем

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

>логичнее табами

Кстати, в пмтоне табы официально преданы анафеме:-)

>Невозможно даже вставить "print something if DEBUG_MODE;"

Вот, специально пошел и вставил. Нажимал:

vim file<CR>18gOif DEBUG_MODE: print something<ESC>

Что тут можно выбросить в случае перла? Да, ставить в первый столбик нельзя. Однако if DEBUG и так вполне явно указывает, что это не часть программы - зачем добавлять "неконсистентность"?

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

Ключевое слово - бездумного. Всё бездумное автоматизируется, и больше не отвлекает.

Конечно, что для полного счастья нужно чтобы редактор сам расставлял отступы и держал на экране начало-конец блоков, если они очень далеко. В случае отступоориентированого синтаксиса это вполне тривиально.

_Компютер_ должен работать.

>простой пробел меняет логику програмы

Опять за своё? У тебя какое-то нездоровое отношение к этому символу:-)

>>простой пробел меняет логику програмы

>Опять за своё? У тебя какое-то нездоровое отношение к этому символу:-)

У меня тоже нездоровое:) По крайней мере, пока в обычной человеческой грамматике паузы различного смысла и логические обороты речи в тексте выделяются соответствующими символами (,.:;?!- и т.п.), а не разним количеством т.н. "символов пробела", я буду считать, что пайтон - для тех, у кого "двойка" в школьной программе по разделу "пунктуация" и кто пишет без знаков препинания (потому как по другому не умеет):)

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

>У меня тоже нездоровое

Признай очевидное - _главный_, и решающий недостаток такого синтаксиса - то, что он _тебе_ не нравится:-)

>значимость пробела имеет значение только для "пайтонистов"

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

>Признай очевидное - _главный_, и решающий недостаток такого синтаксиса - то, что он _тебе_ не нравится:-)

Признаю. И выше сказал ПОЧЕМУ не нравится:)

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

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

> Кстати, в питоне табы официально преданы анафеме:-)

Я помню, что здравомыслящие люди тогда победили, и табы оставили, но это очевидно еще один аргумент к особой нелогичности языка. Уж где-где, а в таком языке один символ обозначающий один отступ был бы намного логичнее, и позволял бы не зажиматься на цифре 4 (или 2 или 8). Выходит, мой код на Perl/C намного логичнее и структурнее отформатирован, чем твой.

> Ключевое слово - бездумного. Всё бездумное автоматизируется, и больше не отвлекает.

Ну да, размечтался. Вот простейший код:

if something:

<TAB>if something_else:

<TAB><TAB>if something_more:

<TAB><TAB><TAB>a = some_function();

Ты хочешь вставить временный print для отладки. И на какой уровень ты (или твой редактор) его поставишь, на 1-ый, 2-ой, 3-ий или 4-ый? Все варианты верны. Заметь, в Perl такой проблемы неоднозначности никогда не возникает, так как все "}" явно проставлены, и твоему умному редактору никогда не надо было бы угадывать неправильно.

> Да, ставить в первый столбик нельзя. Однако if DEBUG и так вполне явно указывает, что это не часть программы - зачем добавлять "неконсистентность"?

Я же сказал, вставить временный print, вовсе необязательно с "if".

> У тебя какое-то нездоровое отношение к этому символу:-)

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

>в Perl такой проблемы неоднозначности никогда не возникает

Наконец-то, после нескольких дней обсуждения мы нашли место, где возникают проблемы при редактировании indent-based синтексиса. Конкретно - проблема есть при вставке кода в место, соответствующее перловому '}}}...}}'. Конечно, поскольку большинство програмистов пишут такой код как

}
}
}
}

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

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

Выволы - ваша неприязнь к offside-rule сугубо субьективна и вызвана привычкой. Я, по правде говоря, с непривычки, запорол пару модулей неаккуратным использованием sw,ts и s/ \+/. Но мне ничего не мешало отнестись к этому делу аккуратнее, поэтому я не виню в этом разработчиков ни синтаксиса ни вима. Восстановил всё минут за пять.

> Что мешает в питоне писать pass в конце блока на случай, если вдруг в этом месте понадобится вставить что-либо

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

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

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

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

Отлично сказано! Ну точно - про "символы пробелов" в пайтоне!:)

Следующий очевидный шаг - полное устранение этого безобразия (   )

:)

>Следующий очевидный шаг - полное устранение этого безобразия ( )

Т.о. эволюционный путь развития стиля "скобок" в языках программирования:

0. "(/)", намного опередившие своё время

1. "BEGIN*/END*"

2. "{/}"

3.

4.

Я пока не вижу, чем п.4 отличается от п.3 (т.к. пробелы невидимы:-), и как этого можно добиться. Вероятно это потребует перехода к редактированию непосредственно AST-ов и отказа от текстового представления программ. Впрочем ты категорически возражаешь против этого, т.ч. непонятно, зачем эту тему поднимать.

>Т.о. эволюционный путь развития стиля "скобок" в языках программирования:

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

>>Т.о. эволюционный путь развития стиля "скобок" в языках программирования:

>то как минимум до этого были ...

Читать умеешь? Перечитай 3 раза 3 слова перед ":", и попытаяся понять, зачем я их туда поставил.

Впрочем, я не претендую на полноту начала списка - допотопные методы практического интереса не представляют:-]

>допотопные методы практического интереса не представляют:-]

Можно и без "знаков препинания" - смотри Forth - там вобще другие понятия, но "слово" из whitespace и здксь никто "не догадался" влепить:)

>Перечитай 3 раза 3 слова перед ":"

Не вижу нигде у тебя ":"

>Не вижу нигде у тебя ":"

Срочно к окулисту.

> для людей, упорно предпочитающих }}}} разносить по нескольким строкам:-)

Ты хотел сказать, для тех, кто хочет правильную структуру, а не безумный хаос. Для тех, кто благоразумно хочет, плавного перехода уровней в своем коде, лишь -1 или +1, а никак не -4.

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

Так думать глубокая ошибка. Это тебе не Lisp, где уровни смешиваются с операторами, и открываются без особой надобности. Тут уровней (if, while, for) не так уж и много, ровно столько сколько попросил. Посему никого кроме себя ублажать не надо, никто кроме тебя не знает где заканчивается блок, это работа программиста.

> Следующий очевидный шаг - полное устранение этого безобразия(}}})

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

Кстати с новым годом.

>Так думать глубокая ошибка

Обоснование давай. В какой предметной области символ '}' в программе что-либо означает? Я утверждаю, что таковых нет(кроме, возможно, каких-то программистских забав типа гольфа или самовыводящихся программ). Сами if-ы,for-ы могут иметь отражение в предметной области, закрывающие же "их" скобки - никогда. Потому, каждый раз, когда ты думаешь о '}' - ты думаешь о синтаксисе, вместо задачи. Т.о. это "синтаксический мусор".

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

> с новым годом

Наверное, это единственное с чем мы всё равно можем согласиться. :)

> Обоснование давай. В какой предметной области символ '}' в программе что-либо означает? [...] Т.о. это "синтаксический мусор".

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

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

> Обоснование давай.

if (a) b; if (c) d; else e;

if { (a) b; if { (c) d; } } else { e; }

if { (a) b; } if { (c) d; } else { e; }

PS. verb. sap.

>Наверное, это единственное с чем мы всё равно можем согласиться.

Если не учитывать несколько календарей, в которых он по другому расположен:-)

>Понятия начала и конца блока (уровень) есть везде, не исключая Python

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

>сотни невидимых символом, грозящих нарушить всю структуру программы

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

>Я же остаюсь со здравым и очень красивым минимализмом

Оставляя в стороне определение "здравости" и "красоты" - минимализм у тебя получился странный. N "концов" - 2*N символов, считая перевод строки и не считая добровольно-принудительных пробелов,с ними не менее N*N. Это по любому больше достигаемого в indent-based синтаксисах O(1).

И какое отношение {}-и имеют к решаемой этим кодом задаче?

> И какое отношение {}-и имеют к решаемой этим кодом задаче?

Видно, "verbum sapienti sat est" тебя не касается. :(

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

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

Причем заметь, "подслащать" слабопортабельным способом, эффективно превращая исходник в _бинарный_, а не текстовый файл.

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

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

Я не говорю, что это плохой язык, я им интенсивно пользуюсь. Но...

>Видно, "verbum sapienti sat est" тебя не касается. :(

Меньше знаешь крепче спишь:-) Этот язык в мои планы пока не входит, т.ч. без перевода возражать не могу.

>записать всё это не в одну строчку, а в шесть

Ну и что? Будучи записаными в 6 строк этот текст не будет требовать от читателя ручного подсчёта скобок(или поиска оных посредством редактора) чтобы понять что оно делает. Ценой всего-лишь нескольких лишних пробелов в файле.

>"пробел" и "перевод строки" получают статус королей, а прочие нон грата

Наглая ложь! Они всего лишь поднимаются до уровня остальных символов, т.е. неравенство устраняется.

>есть оперировать .py как с двоичными

Что всё же намного проще - нужно просто сохранить все символы. И незачем гадать нужны ли этой программе её пробелы.

Кстати, мне кажется тут про перл говорили. Все помнят, что такое format и write(если я не забыл названий) и как оно работает с пробелами?

> без перевода (verbum sapienti sat est) возражать не могу.

А Google на что? :)

> Они всего лишь поднимаются до уровня остальных символов, т.е. неравенство устраняется.

Неравенство устраняется лишь в бинарных файлах. Мы всё таки текстовые файлы обсуждаем.

А вообще спорить с тобой смысла особого нет. У тебя же небось значащий символ ";" мусор, а значащий "\n" для того же самого - не мусор; значащий "}" мусор, а сотни пробелов в предыдущих строках и в последующей составленные определенным образом дабы давать тот же эффект - не мусор.

> Все помнят, что такое format и write(если я не забыл названий) и как оно работает с пробелами?

Нормально работает, и синтаксис подобен inline quoted string <<"ENDSTRING". Так же требует закрытия на первом столбике (кстати, в Perl 6 будет еще больше опций задания inline string). Только вот практика показала, что практически никто не использует format/write, и в Perl 6 вроде бы этих старых функций больше не будет.

Кстати, в Perl 6 скобки при "if", "while" и "for" опциональны.

if 1 + 1 < 3 { say "Ok" } else { die }

>У тебя же небось значащий символ ";" мусор, а значащий "\n" для того же самого - не мусор;

Где я такое говорил? \n и пробелы - тоже мусор, только (твои слова) "невидимый" и (мои) не требующий подсчёта при небольших объёмах/вложености. Что есть хорошо при чтении.

>Нормально работает, и синтаксис подобен inline quoted string

И что, программа выводившая подобным способом будет продолжать выводить так же если ей пообрезать последовательные пробелы, которые были в объявлении fromat? Или она перестанет компилироваться при таких искажениях?

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

>практически никто не использует format/write

Ключевое слово "практически". Т.е. ты заранее не можешь знать, будет ли программа с "оптимизироваными" пробелами работать правильно, не просмотрев перед обрезанием оных в _оригинальном_ тексте все format и inline quoted и прочие string на предмет наличия подряд идущих пробелов.

Даже если считать программу "текстом" в твоём понимании, нет гарантии, что таким же текстом являются её входные/выходные данные, куски которых _могут_ встречаться в коде, и нет гарантии, что все программеры пишут \x20 вместо пробела в строках. Так что указаное тобой отношение к пробелам в текстах программ _неправильно_. Если это до сих пор непонятно - в сад.

Причем тут format. Мы уже обсуждали пробелы в стрингах выше. Не надо смешивать бинарные данные и собственно программу.

Ты, как видно, абсолютно не понимаешь разницы между "один из [десяти] способов отформатировать программу - так как посоветовал Гвидо" и "единственный способ это сделать - так как завещал наш учитель Гвидо; за любые другие языком отрубаются руки, дабы впредь неповадно было".

>Мы уже обсуждали пробелы в стрингах выше

... и наш учитель mihalych завещал нам записывать все пробелы в стрингах виде \040; за любые другие им отрубаются руки...

Только я не видел пока ни одного программиста в стрингах, записывающего все пробелы именно так. Хорошо mihalych далеко живёт :-)

Я сказал, что их _можно_ так записывать в случае надобности. А еще можно считывать бинарные данные из файла, а можно и в виде mime64 засунуть в саму программу, или с помощью '_' закодировать, а может и вовсе с помощью '+' или '%20' (man URI::Escape), да мало ли ещё каким образом обрабатывать данные.

А если уж нетерпится писать программы состоящие _только_ из значимых пробелов и табов, и никаких других символов, то никаких проблем, можно даже автоматизировать: http://search.cpan.org/dist/Acme-Bleach/lib/Acme/Bleach.pm

man perl | grep more

>Я сказал, что их _можно_ так записывать в случае надобности

Но надобность определяется не в момент написания, а в момент появления желания передать _уже_ написаную программу через "кривой" канал/пр. Можешь изобразить такое автоматическое преобразование для произвольного перлового(например) текста, которое бы заменяло _нужные_ пробелы во что-то типа \040, а ненужные удаляло бы? Правильных подходов в этом случае только 1 - прогнать переданое через _соответствующий_ парсер а потом обратно в соотвтествии с желаниями "канала". И это требует знания синтексиса того, что перекодируется. Второй правильный подход ниже.

>А еще можно считывать бинарные данные из файла, а можно и в виде mime64 засунуть в саму программу

А ещё можно передавать програмы как есть(-:или опять же кодировать их в base64:-) - тогда читатель прочтёт именно то, что хотел и написал автор текста, а не то, что думал автор регекспов, преобразующих текст, об том, что может хотеть написать автор текста.

Кажется я понял причину несогласия. У нас разное понимание термина "текст":-). Я пошел думать над описанием своего.

Понял вот что: текст программы есть представление некоего графа(семантического?). Возможно представление этой структуры в виде "одномерного" текста - для этого нужен язык с "видимыми" ограничителями блоков (или со злобным GOTO). indent-dependent представление использует второе измерение. Т.о. оно не является "чистым" текстом и его неудобно передавать в "одномерных" средах, например через голос/уши.

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

Т.о. спор сводится к тому, стоит ли лишняя работа по дополнительной "визуализации" невидимых ограничителей при передаче в "одномерных" средах(1) простоты чтения(2) и естетического удовольствия от меньшего количества видимого мусора(3).

(1) это тривиально, и не так часто нужно

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

(3) субьективно

Очевидно я не считаю (1) существенным критерием, потому "indent рулит!":-)

> Кажется я понял причину несогласия.

Ничего ты не понял. :) Разногласия - в культуре и идиологии. А синтакс лишь их отзвук. Просто для некоторых, прогресс видится как переход от всемогуще-хакерского к убого-трафаретному или даже визуальному программированию. Для других же это полная дегрессия.

Отступнический синтаксис

>переход от всемогуще-хакерского к убого-трафаретному

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

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

>или даже визуальному программированию

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

Более того, если когда-то придумают эффективный трёхмерный интерфейс синтаксис будет иметь смысл заточить под него - сейчас программисты вовсю используют folding - чем не попытка добавить третье измерение в отображение программы?

> AFAIK на доступном ныне железе subj является _оптимальным_ методом передачи сложных структур между человеком и компютером.

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

> Но теперь - о ужас - компютеры справляются с выводом на плоский экран нескольких десятков строк одновременно.

И это не мешает Питону быть одним из самых плохочитаемых языков. Когда ты видишь на экране строки на двух отступах, таких как:

<некий-довольно-большой-пробел>строка 1..20

<пробел-поменьше>строка 21..40

то ты ничего не можешь сказать об этом коде, не подсчитав нудно все пробелы и заранее не зная соглашения о количестве пробелов на уровне. То есть может оказаться, что первые 20 строк относятся к уровню 9, а последующие 20 строк к уровню 6 (а может и 4 или 7). А может и вовсе незаконная программа, не проходящая компиляцию, из-за несоответствия пробелов со строками двадцатью экранами выше. Абсолютно нечитаемый и шаткий для человека язык. И никакой редактор тут не поможет, разве что начнёт гадать, что же на самом деле программист имел тут ввиду и сам попытается раставить недостающие знаки конца блока.

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

> "ed" на dumb-терминале пожалуй требовал линейного синтаксиса.

"ed" идиологически то же, что и "sed", только интерактивный. Построковые редакторы и фильтры были и будут актуальны для манипуляции текста в принципе и текстовых програм в частности (не путать с написанием програм).

> Более того, если когда-то придумают эффективный трёхмерный интерфейс синтаксис будет иметь смысл заточить под него

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

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

Конечно, задача, _требующая_ 20-кратной вложености языковых конструкций будет нечитаема. Но она будет нечитаема _независимо_ от синтаксиса - если её не разбить на мелкие изолированые куски.

>строка 21..40 то ты ничего не можешь сказать об этом коде, не подсчитав нудно все пробелы

А вот тут ты неправ. Я попрошу вим 'zr' столько раз, сколько понадобиться для того, чтобы увидеть интересующий меня кусок кода с нужной "высоты"(в простейшем случае 'zc' в 20й строке будет достаточно). И жесткость питонского синтаксиса почти гарантирует мне безошибочное отображение. Исключения будут только при кривом форматировании продолжений на следующей строке.

Теперь подумай, что будет в той же ситуации с перловым кодом с несбалансироваными '{}' в регекспах, строковых литералах, коментариях, и ошибках синтаксиса. Тебе понадобится полноценный синтаксический разбор. Что намного сложнее простого :set foldmethod=indent.

>То есть ... такой синтаксис не проходит никакой критики.

То есть ты это неподумавши сказал.

>Подточить синтаксис языка или изображение кода в редакторе? Почему-то ты упорно смешиваешь эти два независимые понятия

В системе есть (1)синтаксис(кодировка) текста "на диске", (2)изображение оной на экране и (3)"кнопки", которые нужно было нажать, чтобы получить изображаемый текст. Поскольку компютеру совершенно безразличны все 3 элемента, нужно обеспечить максимальные удобства для человека. Потому это всё можно рассматривать как 1 сущность - пользовательский(програмистский) интерфейс. Очевидно, что по возможности эти элементы должны максимально просто соответствовать друг другу - так человеку проще понять/запомнить. Конечно, это не возможно - в силу разных возможностей устройств. Но копать нужно туда.

Очевидно, что _сейчас_ проще заточить абстрактную сущность(синтаксис) чем заменить все клавиатуры.

>задача, _требующая_ 20-кратной вложености языковых конструкций будет нечитаема.

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

>Но она будет нечитаема _независимо_ от синтаксиса - если её не разбить на мелкие изолированые куски.

А она разбита - начало и конец каждого логического блока чётко отмечено (и эти блоки "взаимно подсвечиваются" в редакторе, если что:))

>Я попрошу вим 'zr' столько раз, сколько понадобиться для того, чтобы увидеть интересующий меня кусок кода с нужной "высоты"

"Опять 25"!:) Vim и "zr" - это уже часть синтаксиса языка???:)))

>>То есть ... такой синтаксис не проходит никакой критики.

>То есть ты это неподумавши сказал.

То есть, то, что "количество пробелов" и термин "синтаксис" никак между собой не связаны по смыслу - ты не осилил:)

Тормози дальше, может повезёт остановиться.

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

Зачем такой длинный синоним для слова "слил"?:)

>Зачем такой длинный синоним для слова "слил"

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

а Led дело говорит...

>а Led дело говорит...

Определим п.(1) как 'Тут автор вякнул ради самого процесса'.

Дело? Давай посмотрим. Led сказал такое:

/* Принесём извинения Led-у за резкий тон */

>Книжка с количеством абзацев в главе более 10-и будет нечитаемой...

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

><некий-довольно-большой-пробел>строка 1..20\n<пробел-поменьше>строка 21..40

=> п.(1)

>А она разбита - начало и конец каждого логического блока чётко отмечено (и эти блоки "взаимно подсвечиваются" в редакторе, если что:))

А Led пробовал написать в .pl файлике такой фрагмент кода (с блоками на 20 строк каждый) и посмотреть, как выглядит подсвеченая '{', расположеная на 3 сантиметра выше верхнего края экрана? Скриншот в студию:-]

=> п.(1)

>"Опять 25"!:) Vim и "zr" - это уже часть синтаксиса языка???:)))

А Led читает тексты прямо из ОЗУ минуя "редактор"? Или _неправильная_ подсветка, упомянутая в прошлом параграфе, является частью синтаксиса? Или Led попробовал ввести в .pl файлике что-то типа

if (1) { m/some{{{s/ ; print "more {{s"; # even more {{{s

и посмотреть, что подсвечивает его любимый редактор при вводе последующих '}' ? Или Led смог запрограммировать свой редактор так, что это работает правильно, не встроив в него полноценный синтаксический анализатор? Или он попыталься получить удовольствие от подсчёта вручную в таком же тексте на несколько страниц ?

=> п.(1)

>То есть, то, что "количество пробелов" и термин "синтаксис" никак между собой не связаны по смыслу - ты не осилил:)

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

=> п.(1)

А где же дело, которое сказал Led? => п.(1)

>Насколько я понял, этот термин означает "уход от темы".

Да, как правило это и обозначает. Вот только я так и не понял, почему ты заменил этот термин таким длинным синонимом?:)

>почему ты заменил этот термин таким длинным синонимом

Потому что ты не "сливал" а "чушь порол". См. выше ответ анонимусу, то же порящему.