LINUX.ORG.RU

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


0

0

"Как известно, впервые Perl был представлен на суд общественности Ларри Уоллом (Larry Wall) еще в конце 1987 г. В последующие несколько лет язык бурно развивался, одна за другой выходили новые версии, и уже в 1994 г. программисты работали с Perl 5. Однако с тех пор прошло тринадцать лет, и хотя за это время появлялись очередные релизы, номер текущей версии по-прежнему начинается с пятерки. Значит ли это, что Perl идеален? Спору нет, он очень хорош, но и предела совершенствованию, как известно, нет. А одна из причин задержки шестой версии состоит в том, что в ней ожидается поистине революционное новшество - переход на новую систему промежуточного представления кода."

>>> Статья на itc.ua



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

Ответ на: комментарий от Hjorn

> Соответственно определение блока

Определение хэша то бишь.

Hjorn
()
Ответ на: комментарий от mihalych

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

И забыть про ООП?

Hjorn
()
Ответ на: комментарий от mihalych

> и добавлением большого числа реальных проблем.

Каких именно проблем? Перечисли большое число, плз. У меня их вообще нет.

> Ну, если только мелкие програмки на пол странички распечатываешь

Последний раз я листинги распечатывал на дипломе. Питонские, что характерно, ~ 2K LOC. А зачем их вообще печатать-то?

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

"Неумышленная потеря" - это как? Винт сдох, файл удалили враги? А причём тут синтаксис питона?

Единственно верная среда существования кода - текстовый файл. А в нём, при грамотном обращении, с отступами ничегошеньки не случится.

Копипаст - не проблема. При неправильном копипасте неизбежен SyntaxError. Форумы - не проблема. Практически везде есть режим сохранения отступов.

Читать код без скобок приятнее. Диффы чище. Coding style определяется проще.

yk4ever
()
Ответ на: комментарий от yk4ever

>Каких именно проблем? Перечисли большое число, плз. У меня их вообще нет.

У тех, кто пишет на asm их тоже нет. А у VB-филов еще меньше - в головах у них просто проблемы не помещаются:)

>А зачем их вообще печатать-то?

И правда: пока не печаеташь - и проблем нет!:)

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

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

>Копипаст - не проблема. При неправильном копипасте неизбежен SyntaxError.

Не-неизбежен.

>Читать код без скобок приятнее.

Аллергия на скобки?

>Диффы чище.

Ага, только diff/patch с ограничеениями нужно использовать.

>Coding style определяется проще.

Сам-то понял что сказал?:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

>И правда: пока не печаеташь - и проблем нет!:)

Ответь на вопроы - зачем нужно печатать?

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

Можешь объяснить, зачем надо считать пробелы?

Ты что, в скобочных языках всегда тщательно скобки считаешь?

> Не-неизбежен.

Приведи пример. Неправильный copy-paste без SyntaxError. Время пошло.

> Ага, только diff/patch с ограничеениями нужно использовать.

С какими, например?

> Сам-то понял что сказал?:)

Мальчег, я перенапряг твой моск? Иди, пей пиво дальше.

yk4ever
()
Ответ на: комментарий от yk4ever

>Ответь на вопроы - зачем нужно печатать?

без комментариев:)

>Можешь объяснить, зачем надо считать пробелы?

Чтоб не допустить ошибку. Или чтобы найти её.

>Приведи пример. Неправильный copy-paste без SyntaxError. Время пошло.

Уже приводили. Но ты не чиататель, а "писатель".

>С какими, например?

man diff

man patch

Чтение манов вслух и с выражением - только за деньги:)

>Мальчег, я перенапряг твой моск? Иди, пей пиво дальше.

Зачем так длинно? Скажи просто: "сливаю..."

Led ★★★☆☆
()
Ответ на: комментарий от Led

>> Приведи пример. Неправильный copy-paste без SyntaxError. Время пошло > Уже приводили.

Это не пример, а говно: >>> if something: ... print 1 File "<stdin>", line 2 print 1 ^ IndentationError: expected an indented block

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

anonymous
()
Ответ на: комментарий от anonymous

>>> if something:
... print 1
  File "<stdin>", line 2
    print 1
        ^

anonymous
()
Ответ на: комментарий от Led

> без комментариев:)

Раз слив.

> Чтоб не допустить ошибку. Или чтобы найти её.

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

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

> Уже приводили.

Про идиотизм этого "примера" подробно объяснили три человека. Два слив.

> Чтение манов вслух и с выражением - только за деньги:)

Короче, вякнул, а объяснить не можешь. Три слив.

Три слива в одном посте, мальчег. Будешь квакать дальше или таки приведёшь вменяемые примеры?

yk4ever
()
Ответ на: комментарий от yk4ever

> Каких именно проблем? Перечисли большое число, плз. У меня их вообще нет.

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

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

> А зачем их вообще печатать-то?

А как же тогда код DeCSS на майке сохранить? В электронном виде запрещено. :-)

> Единственно верная среда существования кода - текстовый файл.

Глупости полнейшие. Топик о динамических языках, а значит, как минимум есть ещё стринги, содержащие динамический код на выполнение. А ещё код может быть на бумаге, на майке, в сообщении форума, на веб странице (в форме HTML), на экране, в коммандной строке. А ещё можно код по телефону начитывать сисадмину, не знающему програмирования, когда ты в круизе без интернета, а у него проблема случилась. Например так: "далее надо добавить условие X, начало блока, Y, Z, конец блока", или так: "далее надо добавить новую строку, 16, ой нет, 20 пробелов, условие X, новую строку, 24 пробела, Y, новую строку, 24 пробела, Z, новую строку". А ещё за экраном может сидеть плоховидящий, который читает и пишет по системе Брайля. Да мало ли что может с кодом случиться. И во всех этих случаях получаем проблемы, причём без решения в общем случае. Так зачем же создавать столько потенциальных проблем (а для многих они не потенциальные, а ежедневные), когда есть полноценные синтаксисы без проблем.

> Копипаст - не проблема.

Проблема, и ещё какая. Что именно из того, что я выше писал (#1963715) не понятно? Неужели ум питониста так узок, чтобы не понять, что текстовый редактор тут абсолютно ни при чём. Повторю частую задачу при написании кода. Надо перенести (или скопировать, если так уж привязались к copy-paste) немаленький кусок кода, но при этом поставить его на правильный уровень индентации, да и подправить по ходу кое где код (добавить или убрать пару условий к подблокам). Начинаем построчно подравнивать индентацию, дабы наш блок встал на своё место и добавлять условия, и упс, насередине имеем пол блока исправленного и пол блока нет. Информации о начале и конце оригинальных подблоков утеряна (так как её попросту никогда и не было). Что делать? Хоть полный undo делай, чтобы подсмотреть какая логика в оригинале была. Такая проблема (при подправлении уровней и добавлении блока if {}) просто не возникает в нормальном синтаксисе, где присутствует полная информация о начале и конце блока и лишний TAB не поменяет логики. Убрать из синтаксиса такую важную информацию - это сделать процесс редактирования невыносимым в общем случае.

> Читать код без скобок приятнее.

Это индивидуально. Мне со скобками понятней, а следовательно приятней.

> Диффы чище.

Для моего стиля это абсолютно неверное утверждение. А те вещи, у которых нет эквивалентного синтаксиса и сравнивать нельзя. Я бы сказал так: диффы одинаково чистые в хорошем коде на обоих языках. А вот когда изменения были в добавлении уровня (добавлено условие вокруг блока), то диффы одинаково плохочитаемые на обоих языках. Много строк с минусами, а потом много строк с плюсами. Зато (внимание!), если запускать diff с опцией --ignore-all-space, то получим чистый и верный дифф (добавлены начало и конец блока, а индентация осталась старой, от неё смысл и понимание того, что было добавлено, никак не меняются). А в случае Питона, получаем чистый, но неверный дифф (никак нельзя будет понять, что конкретно изменено, а что нет, отсутствует информация)!

Поклонники Питона, хватит уже показывать, как вам не нужны памперсы или телескопы, и следовательно это вредные и никому не нужные вещи. Просто глупая логика.

mihalych ★★★
()
Ответ на: комментарий от mihalych

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

В строках никогда не было проблемы с добавлением \n.

> А ещё код может быть на бумаге, на майке, в сообщении форума, на веб странице (в форме HTML), на экране, в коммандной строке.

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

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

Наверное, проще начитывать сразу уборщице.

> Например так: "далее надо добавить условие X, начало блока, Y, Z, конец блока"

На питоне это будет звучать точно так же. Какие проблемы? Зачем число пробелов рассказывать? У уборщицы нету нормального редактора?

> Начинаем построчно подравнивать индентацию,

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

> А в случае Питона, получаем чистый, но неверный дифф (никак нельзя будет понять, что конкретно изменено, а что нет, отсутствует информация)!

O RLY? diff -U 3 -w и всё видно не хуже чем в перле.

Хотя, подчеркнём, нормальные люди пользуются визуальными средствами показа диффов.

yk4ever
()
Ответ на: комментарий от yk4ever

> В строках никогда не было проблемы с добавлением \n.

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

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

Посмотри на все мои сообщения в этом топике. Длинные обзацы плюс немного кода, причём прекрасно читаемого, несмотря на то, что не используется "Preformatted text". Если бы я использовал этот режим, то ты бы сейчас не вертикально этот топик читал, а дёргая по 100 раз скроллбар слева направо и опять налево. Но ты продолжаешь утверждать, что "В форумах проблем нет". Глупо.

Я говорю: "не стоит по своему бедному списку задач судить о задачах других", а ты: "На бумаге и майке кода быть не должно. В командной строке кода быть не должно". Очень глупо.

> Наверное, проще начитывать сразу уборщице.

Не знаю, как у вас поддержка кода по разным отделам происходит, но мне часто приходится наговаривать API по телефону. Причём как тем, кто хорошо знает Perl, так и тем, кто в основном умеют copy-paste-edit делать. Только сейчас представил, какая бы дополнительная морока была, использовали б мы Питон. Сколько недопонимания и новых путей сделать невидимую ошибку. Те, кто исправлял ошибки по телефону, направляя оператора, поймёт.

> У уборщицы нету нормального редактора?

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

> Наверное, проще сразу застрелиться.

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

> O RLY? diff -U 3 -w и всё видно не хуже чем в перле.

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

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

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

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

mihalych ★★★
()
Ответ на: комментарий от mihalych

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

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

> Длинные обзацы плюс немного кода, причём прекрасно читаемого,

Да чё-то ничего читаемого и осмысленного пока не видел.

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

А ты его аккуратно используй.

> но мне часто приходится наговаривать API по телефону.

Жёстко у вас всё. SSH, email и ICQ до вашей деревни не дошли?

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

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

> В том-то и дело, что после этой комманды ты увидишь лишь, что добавлен блок (начало блока),

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

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

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

А для тех, кому СМЕРТЕЛЬНО не хватает скобог, всегда есть:

http://www.python.org/doc/Humor.html#parsing

yk4ever
()
Ответ на: комментарий от mihalych

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

Жесть! :) Представляю себе, как Михалыч начитывает по телефону:

@sorted = map {$_->[1]} sort {$a->[0] <=> $b->[0]} map {[length $_, $_]} @list

Любопытно было бы послушать :D

Hjorn
()
Ответ на: комментарий от Hjorn

>Любопытно было бы послушать

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

Led ★★★☆☆
()
Ответ на: комментарий от Hjorn

> Представляю себе, как Михалыч начитывает по телефону

Приходилось начитывать подобное, а то и покруче. А что делать, если ты не за компьютером (в отпуске, скажем), а кому-то срочно требуется в продакшн мелкие изменения сделать, подправить логику или сортировку, дабы учитывать в ней какое-то новое поле. Так и начитываешь, посимвольно. За минуту готово. Эффективней email/sms или физического присутствия.

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

mihalych ★★★
()
Ответ на: комментарий от mihalych

Гыгы телефон не нужен, по нему отступы не сделаешь.

anonymous
()
Ответ на: комментарий от yk4ever

> То есть ты в скобочных языках в ходе переделки кода любишь рушить отступы.

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

> А ты его аккуратно используй.

Чтобы аккуратно использовать режим "Preformatted text" надо отдельно постить код, и отдельно комментарии, потому как дисскусия в форумах моноспейсным шрифтом не ведётся. Для нормальных языков такой режим необязателен.

> Жёстко у вас всё. SSH, email и ICQ до вашей деревни не дошли?

Дошли, лет 10 назад. А для документации используем веб. Но ведь и через Google умеючи можно почти на любой вопрос найти ответ; означяет ли это, что потребность в специалистах отпала?

> Правильный ответ - сличение пробельного и безпробельного диффов.

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

> А самый правильный - использование визуальных средств.

Самый правильный - использовать явный символ конца блока и забыть о проблемах.

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

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

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

> А для тех, кому СМЕРТЕЛЬНО не хватает скобог, всегда есть: Humor.html

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

mihalych ★★★
()
Ответ на: комментарий от mihalych

Mihalych, Спасибо большое. Нет, ОЧЕНЬ большое спасибо за вразумительность позиции, выдержку. За то, что не бросили дисскусию посередине (Хотя, поводов для многих других было бы предостаточно). Ваши доводы помогли избавиться от некоторых сомнений и предопределили мой выбор.

Seclorum
()
Ответ на: комментарий от Seclorum

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

kto_tama ★★★★★
()
Ответ на: комментарий от mihalych

Поздравляю, михалыч, не менее 3х удалось обмануть (: включая себя :). Аргументы:

>данном случае речь шла о генерации кода на выполнение

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

>Дифф, который по умолчанию, нечитаем ... не может быть правильным

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

>К сожалению, это всего лишь юмор

Не "всего лишь" - на самом деле это решение проблемы передачи кода по телефону. Диктуешь "#{<Enter>" "<Enter>#}" каждый раз, когда нужно открыть/закрыть блок, а потом что-то типа:

:set nows<Enter>qq/#{$<Enter>l%mq%xxj>`qq666@q

(вполне себе в духе перла) и твой (точнее наш) код выстраивается как нужно :)

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

>>Дифф, который по умолчанию, нечитаем ... не может быть правильным

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

Для каждого языка - свой diff? и для кадой его версии - тоже? Что за бред? Сначала под пайтон нужен спец-редактор, потом, оказывается, и свой diff с patch'ем. Что ещё? Напишите ОС, заточенную для Python и резвитесь себе в ней (PythonFS тоже не забудьте):)

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

Если в атомобиле есть пятое колесо (сбоку), но отсутствует четвёртое, то это именно проблема и автомобиля, и мозга тех, кто его придумал, и тех, кто на нём катается с криками "Рулез!"

Led ★★★☆☆
()
Ответ на: комментарий от kto_tama

Похоже перловые неофиты просто не знают, что значительная часть работы программиста - это сопровождение и улучшение старого кода. И вот тут то недостатки питоновского синтаксиса выглядят сущей мелочью по сравнению с синтаксическими извратами перловки. Особенно если оная была писана левой пяткой хакира, не нашедшего лучшего способа для самовыражения. Короче, всем неофитам читать "The Elements of Programming Style" (Kernighan, Plauger) и думать, пока не поздно.

anonymous
()
Ответ на: комментарий от Led

>Для каждого языка - свой diff

Мне это тоже не очень нравится. Но что поделаешь - если нечто кодируется не как "набор строк", программы обработки последнего будут выдавать странные результаты. По правде говоря это же относится и к перловому и любому другому коду - гипотетический "ситнаксически-просвещённый дифф" будет давать намного более интересные результаты, особенно для любимых михаличем однострочников, а тот, что мы имеем сейчас - "one size doesn't fit at all" - какие может. Неприспособленость молотка к "установке" шурупов не есть недостаток последних.

>то это именно проблема и автомобиля

Ещё раз - автомобиль приспособлен к широким "2мерным" дорогам, применение его там, где таковых нет, малоэффективно. Ходить пешком, конечно, более гибко - если что перепрыгнуть можно, и через разного рода трубы пролазить. Только медленно, и дождь на голову капает.

Точно так же отступнический синтаксис приспособлен к 2мерным средствам отображения. Но при этом у нас есть эти самые средства, и наши мозги вполне приемлемо справляются с 2мерными обьектами. Зачем между ними (мозгами и программой) иметь "одномерный" канал/синтаксис?

DonkeyHot ★★★★★
()
Ответ на: комментарий от Led

PS: про диф

>Для каждого языка - свой diff

Ну, научили же его игнорировать отступы. Что мешает научить "считать" их? Опять же, это не только питону со товарищи поможет, т.к. практически все это(отступы) применяют.

DonkeyHot ★★★★★
()
Ответ на: PS: про диф от DonkeyHot

>Ну, научили же его игнорировать отступы. Что мешает научить "считать" их?

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

Led ★★★☆☆
()
Ответ на: комментарий от Led

>мы получим книжки ...

Довольно неуклюжая попытка обмануть народ - сравнивать правила выделения "параграфов" с правилами выделения и структурирования предложений. Незачёт.

Что до блоков, не знаю как сейчас, но во времена, когда я её массово читал в иностранной печатной доке именно так их и выделяли. Может в последнее время что-то изменилось?

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от Led

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

Значит по-твоему абзацы придумали красноглазые пайтоно-фанаты? :D Ну-ну. Похоже си-подобный синтакс разъедает моск посильнее, чем пайтоновские отступы. Между прочим, аналог точки есть и в Пайтоне, если ты не знал. Только он избыточен в большинстве случаев.

anonymous
()
Ответ на: комментарий от anonymous

Последний anonymous: тут научный спор идёт о неполноценности синтаксиса Питона. Зачем же блистать своим незнанием, чем O(1) отличается от O(N).

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

Впрочем, я бы не стал сильно углубляться в подобные аналогии; есть посильнее аргументы против синтаксиса Питона.

mihalych ★★★
()
Ответ на: комментарий от DonkeyHot

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

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

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

То есть программы должны писаться исключительно для "компютеров" и любые попытки сделать синтаксис для "человеков" должны пресекаться. Ты мне про то, что Питон - Turing complete, так с этим никто и не спорит. Значит ли это, что синтаксис Питона хорош? Ни в коем случае.

> Человеку, отстаивающему независимость от инструмента(дифа в д.с.), это не должно казаться недостатком сравниваемого. Это просто применение неправильного инструмента.

Абсолютная ложь. Я лет 10 пользуюсь diff-ом, обычно с флагом "-u", но иногда и с "--ignore-all-space" или подобными. Волее того, никогда не делаю commit без diff. Это правильный инструмент для языков с нормальным синтаксисом. То, что он не работает для Питона говорит лишь о проблемах синтаксиса языка, а не инструмента.

> Не "всего лишь" - на самом деле это решение проблемы передачи кода по телефону.

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

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

2) Нельзя запросто перескочить на конец блока, найдя соответствующую скобку.

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

4) Вышеназванные проблемы с diff.

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

1) По телефону всё же придётся начитывать число начальных пробелов в каждой строке. (По поводу умных редакторов, спорь с другим ярым Питонистом yk4ever, который выше матом крыл vi (#1963737). Для меня же нормальный редактор это тот, что вставляет один настоящий Tab по нажатию одноимённой клавиши и стирает ровно один символ по нажатию Backspace. Всё остальное - от лукавого.)

2) Произвольное разделение на строки (или всё в одну строку) не позволяется.

3) Работать со стрингами кода сложно по сравнению с нормальными синтаксисами.

4) Вставлять временный код на минуту в нулевой столбик никак нельзя. Вставить временное условие вокруг блока (не меняя ничего в самом блоке) никак нельзя. Такие глупые ограничения просто невыносимы для скриптового языка.

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

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

7) Конструкции языка невыносимо урезаны в связи с неполноценностью синтаксиса. Так, несколько полноценных анонимных блоков на выражение просто принципиально не возможны. Хотя, что там, покаместь даже один анонимный блок внутри выражения не поддерживается.

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

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

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

> Точно так же отступнический синтаксис приспособлен к 2мерным средствам отображения. Но при этом у нас есть эти самые средства, и наши мозги вполне приемлемо справляются с 2мерными обьектами. Зачем между ними (мозгами и программой) иметь "одномерный" канал/синтаксис?

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

> Ну, научили же его игнорировать отступы. Что мешает научить "считать" их?

Эта задача не определена в рамках методологии diff. Да и рассматриваем мы тут наглядность показа изменений в уровнях без потери верности. Решить проблему отсутствия явного обозначения конца блока можно лишь его добавлением, любое другое решение в лучшем случае будет неполным.

mihalych ★★★
()
Ответ на: комментарий от mihalych

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

1.То, что молоток плохо забивает шурупы, является проблемой шурупов - с гвоздями всё ОК.

>То есть программы должны писаться исключительно для "компютеров" и любые попытки сделать синтаксис для "человеков" должны пресекаться

2. Это я про то, что "отступы" создают проблемы при генерации/разборе кода. Не создают. А отступы как раз человеку _проще_ "парсить". И не нужно говорить про много подряд идущих закрытий блоков - в аналогичном коде '}}}}}' человеку разобраться так же трудно.

>Я лет 10 пользуюсь diff-ом, обычно с флагом "-u" ... Это правильный инструмент для языков с нормальным синтаксисом

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

>>это решение проблемы передачи кода по телефону.

>Ложь

4. Где я соврал? Я показал, как с использованием этого "метода" можно диктовать питонский код без подсчёта отступов. Опровержение давай.

>не видно где блок кончается, надо гадать на глаз

5. Уже было. В случае коротких блоков всё просто, в случае длинных '}' не помогут, т.к. либо начало либо конец уедут за край экрана.

>Нельзя запросто перескочить на конец блока, найдя соответствующую скобку

6. Нужно полагать, ты эту скобку "вручную" ищешь? Могу спорить, что нет, ты нажимаешь '%' (или что там в твоём редакторе). Догадаешся, как сделать переход на начало/конец питонского блока из foldинга и макросов, например? Будешь удверждать, что твой редактор от этого упадёт от усталости?

>По телефону всё же придётся начитывать число начальных пробелов

7. Перечитай пост, на который отвечаешь.

>Произвольное разделение на строки (...) не позволяется.

>Работать со стрингами кода сложно по сравнению с нормальными синтаксисами.

8,9. См. спеки.

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

10. добавь к прошлой строке ';\'. 'никак' опровергнуто?

>Вставить временное условие вокруг блока (не меняя ничего в самом блоке) никак нельзя.

11. это легко делаеться несколько раз, если для выделения используется больше одного пробела. 'никак' опровергнуто?

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

12. На самом деле не "всевозможные" - а "одна возможная" проблема передачи кода внутри html людьми, забывающими про "pre".

>Давай посмотрим, кто же из нас обманывает

Итого - 12 раз откровенная ложь. Ах да, 13:

>Я-то как раз говорю правду и только правду.

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

Остальные просто спорны:

>Нельзя исправить ошибочную индентацию (в том числе с помощью такого хорошего инструмента как indent) в самых простейших случаях

Ну да, конечно. А то, что indent не вставляет пропущеные "{}", является фатальным недостатком перла,C, C++, Явы и ещё десятка языков.

>просто пройтись и добавить или убрать построчно один уровень

А зачем делать это построчно? В твоём редакторе невозможно сдвинуть выделеный блок?

>Конструкции языка невыносимо урезаны в связи с неполноценностью синтаксиса

Тот же Хаскель с отступами работает и с конструкциями всё в порядке. Т.ч. связь с "отступами" довольно слабая. IMHO.

>ни с двухмерным видением мозгов

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

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

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

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

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

>Эта задача не определена в рамках методологии diff. Да и рассматриваем мы тут наглядность показа изменений в уровнях без потери верности

Когда ты последний раз видел вывод diff-а? Видел там такое:

>@@ -2,7 +2,7 @@

То есть дифф уже явно указывает начало и конец изменившегося блока. Что стоит добавить туда сообщение типа "сдвинуто вправо на 4"? Или diff - догма? Как быть, например, с darcs-овым дифом, который умеет обрабатывать "token replace" патчи? Он некошерный и должен быть подвергнуть анафеме?

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

>1.То, что молоток плохо забивает шурупы, является проблемой шурупов - с гвоздями всё ОК.

Не "шуропов", а одного конкретного шурупА под названием Python. Т.о. только Python - "в ногу"?:)

За остальное - зачот! Знатно посмеялся, даже закопипастил цитаты (хоть это и "вредная привычка"), как нибудь ещё откопаю и посмеюсь:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

>Не "шуропов", а одного конкретного шурупА под названием Python

Выделение блоков отступами не только в питоне используется, и Гвидо не первый.

DonkeyHot ★★★★★
()
Ответ на: комментарий от mihalych

> 1) По телефону всё же придётся начитывать число начальных пробелов в каждой строке.

Да уж, убийственный аргумент против Питона. Если ты начитываешь посимвольно, то сказать 'Tab' для нового уровня индентации и 'Backspace' для сдвига на уровень влево не так уж и сложно. А простой auto-indent нынче умеют почти все редакторы. Да и для "непрограммиста" код, нормально разбитый по строкам и без магических заклинаний {$_@%} будет всяко понятнее. Отсюда меньше вероятность, что он запорет всю конструкцию, пропустив доллар или скобочку. Да и ты можешь где-то банально забыть сказать 'доллар', и будете вы долго и нудно выяснять, в чем же проблема.

> 2) Произвольное разделение на строки (или всё в одну строку) не позволяется.

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

> 3) Работать со стрингами кода сложно по сравнению с нормальными синтаксисами.

Ты с чем чаще работаешь, непосредственно с кодом или со стрингами? Сложность кодогенерации - ничто по сравнению со сложностью восприятия кода.

> 4) Вставлять временный код на минуту в нулевой столбик никак нельзя. Вставить временное условие вокруг блока (не меняя ничего в самом блоке) никак нельзя.

Тебе уже показали как это сделать. Теперь объясни зачем? Подозреваю затем, что в перле нет assertions.

> 5) Править немаленький код - опасно, в том числе просто пройтись и добавить или убрать построчно один уровень (очень частая операция).

Ты серьёзно добавляешь/убираешь уровни построчно? Всё таки тебе определённо нужен хороший текстовый редактор, безотносительно питона.

> 6) Копировать из другого места (как с теми же символами, используемыми для индентации, так и с совсем другими; с тем или иным уровнем) - просто опасно.

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

> 7) Конструкции языка невыносимо урезаны в связи с неполноценностью синтаксиса. Так, несколько полноценных анонимных блоков на выражение просто принципиально не возможны. Хотя, что там, покаместь даже один анонимный блок внутри выражения не поддерживается.

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

http://www.artima.com/weblogs/viewpost.jsp?thread=147358

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

> 8) Всевозможные проблемы, связанные с передачей кода через различные популярные медии

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

anonymous
()
Ответ на: комментарий от DonkeyHot

> 1.То, что молоток плохо забивает шурупы, является проблемой шурупов - с гвоздями всё ОК.

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

> 2. Это я про то, что "отступы" создают проблемы при генерации/разборе кода. Не создают.

Не надо врать. Создают. В нормальных синтаксисах, имея стринги кода X и Y можно тривиально (исключительно добавлением) сделать производную конструкцию. X; Y. Или if cond { X } else { Y }. Не меняя никак при этом самих X и Y. В Питоне для каждой манипуляции надо парсировать и изменять сами X и Y, крайне ресурсо неэффективно. Не говоря уже о длине бессмысленного кода в виде тонны индентации, которая путается под ногами как генератора, так и парсера.

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

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

К якобы более лёгким случаям, как { A { if { B } else { C } } D } всё вышесказанное относится в той же мере как и к "}}}}}".

> 3. Предлагаю эксперимент. Возьми перловую програмку из нескольких строк, соедини их в одну, и сравни diff-ом с оригинальной. Код остался тем же, а на выходе - куча "мусора". Вывод - диф неправильно определяет изменения в _перловом_ коде.

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

> Догадаешся, как сделать переход на начало/конец питонского блока из foldинга и макросов, например?

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

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

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

> 5. Уже было. В случае коротких блоков всё просто, в случае длинных '}' не помогут, т.к. либо начало либо конец уедут за край экрана.

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

> 7. Перечитай пост, на который отвечаешь.

Я прав в общем случае.

> 8,9. См. спеки.

Посмотрел. Это никак не изменило верность моих высказываний.

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

> 10. добавь к прошлой строке ';\'. 'никак' опровергнуто?

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

> > Вставить временное условие вокруг блока (не меняя ничего в самом блоке) никак нельзя.

> 11. это легко делаеться несколько раз, если для выделения используется больше одного пробела. 'никак' опровергнуто?

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

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

> 12. На самом деле не "всевозможные" - а "одна возможная" проблема передачи кода внутри html людьми, забывающими про "pre".

Я привёл 2 примера, когда значимая информация непроизвольно теряется в отличии от нормальных синтаксисов (кто-то написал сообщение в форуме; кто-то опубликовал program.py на веб сервере, а тот выдал Content-Type: text/html); и даже добавил "и многое другое", то есть уже никак не "одна возможная" проблема. Если тебе хочется раскрыть обсуждение того, что я свёл в один пункт и получить список многочисленных проблемных случаев встречающиеся в реальной жизни, мы можем это сделать. Но выдумывать незачем.

> > Давай посмотрим, кто же из нас обманывает

> Итого - 12 раз откровенная ложь. Ах да, 13

Значит выходит так. Я привёл 4+9=13 аргументов в доказательство ущербности синтаксиса Питона, ни одно из которых не было опровергнуто. В ответ же я получил 13 высказываний, ни одно из которых не верно в общем случае. В итоге меня обвиняют во лжи. Я могу понимять желание закрыть глаза на проблемы любимого языка, тем более если кто-то в связи с спецификой своих задач может не очень часто с ними встречаться или уже привык к ним. Но до такого скатываться не стоит, я-то за свои слова на этом форуме отвечаю.

mihalych ★★★
()
Ответ на: комментарий от DonkeyHot

> > Нельзя исправить ошибочную индентацию (в том числе с помощью такого хорошего инструмента как indent) в самых простейших случаях

> Ну да, конечно. А то, что indent не вставляет пропущеные "{}", является фатальным недостатком перла,C, C++, Явы и ещё десятка языков.

Пропущеные "{}" коих один-два-три никак нельзя сравнить с пропусками чего-то в тонне невидимой, но значимой индентации. Это на порядки различные проблемы, как количественно, так и качественно.

> > просто пройтись и добавить или убрать построчно один уровень

> А зачем делать это построчно? В твоём редакторе невозможно сдвинуть выделеный блок?

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

> О! Наш мозг распознаёт образы _намного_ быстрее, чем считает скобки.

Хотелось бы всё же научного обоснования, каким образом образ длины пробела в 15 сантиметров (а не 12 или 16) распознаётся мозгом лучше, чем 5 скобок. Да ещё и для каждой строчки. Это прямо какая-то задача "найди 7 различий между длинами пробелов в строчках" выходит, а не программирование.

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

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

Тут мы не сходимся ни в чём. Я не согласен, что представление кода кому-то что-то _обязано_ (лучше, когда оно просто гибкое), и с тем, что Питонов код заточен под восприятие человеком.

> Когда ты последний раз видел вывод diff-а? Видел там такое:

Ежедневно вижу, я же говорил про commit.

> То есть дифф уже явно указывает начало и конец изменившегося блока. Что стоит добавить туда сообщение типа "сдвинуто вправо на 4"?

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

> Как быть, например, с darcs-овым дифом, который умеет обрабатывать "token replace" патчи?

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

mihalych ★★★
()
Ответ на: комментарий от anonymous

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

Все аргументы против синтаксиса Питона, что я привёл в родительском посте (4 плюс 9 плюс 1 про diff) взяты из моего реального опыта. И приведённые проблемы являются фундаментальными, покаместь меня не смогли разубедить. Они на то и фундаментальные, что от замены текстового редактора или чего бы то ещё не исчезнут.

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

mihalych ★★★
()
Ответ на: комментарий от mihalych

>имея стринги кода X и Y можно тривиально

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

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

Спорим, ты научился выстраивать кубики в ряд намного раньше, чем считать до пяти?

>Перед сравнением ... пройдись по ним с помощью indent

Читай внимательно. сегодняшний диф может выдать большие отличия для 2х "абсолютно" идентичных программ. А может и не выдать - зависит от того, какой стиль индентации применялся. Вывод - он работает неправильно относительно рассматриваемых данных.

>Все видимые '{' и '}' определяют границы видимых блоков...даже если часть блока находится вне видимости

Сколько блоков открыто в тексте {"{{{{{{{"} ? А если скобка спряталась за правым краем экрана в "nowrap" режиме редактора? А если она "психологически" невидима - спрятана между 2мя регекспами с кучей "{/;}"? Тщательнее нужно.

То ли дело в питоне - отступ не изменился увеличился - блока нет.

>как конкретно, имея любой блок, временно добавить или временно удалить условие вокруг

См. следующее сообщение

>а тот выдал Content-Type: text/html

А я что говорил - ключевое слово HTML.

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

>А если скобка спряталась за правым краем экрана в "nowrap" режиме редактора?

А если строка python-кода за-wrap'илась во "warp" режиме редактора? или при печати? Сразу получаешь рак мозга и убиваешь себя ап стену?

Led ★★★☆☆
()
Ответ на: комментарий от mihalych

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

Оригинал:
...
  if a:
    b
    c
...

с добавленым условием:
...
 if временное условое:
  if a:
    b
    c
...

В "стандартном" оформлении используется 4 пробела, т.ч. 3 условия вполне вставляются.

Но это опять таки - решаем проблемы метода решения. 
Проще попросить vcs откатить дебажные изменения.

DonkeyHot ★★★★★
()
Ответ на: комментарий от mihalych

>Так что не ври, что в Питоне есть понятие конца блока в редактируемом (не окончательном) коде

Михалыч, не тормози. В любом недописаном питонском коде конец блока есть (:пока ты не начнёшь генерировать его в хаскелевых бесконечных строках:)

>Не опровергнуто... >В ответ же я получил 13 высказываний, ни одно из которых не верно в общем случае

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

>за свои слова на этом форуме отвечаю

Так что сказал "никак" - должно быть "никак". А если в некоторых случаях всё же "как" - выражайся точнее, или "отвечай".

DonkeyHot ★★★★★
()
Ответ на: комментарий от Led

>А если строка python-кода за-wrap'илась во "warp"

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

>>А если строка python-кода за-wrap'илась во "warp"

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

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

А ты не знал, что в большинстве нормальных языков "не обязательно писать строки такой длинны" (кстати, какой?)?

Led ★★★☆☆
()
Ответ на: комментарий от mihalych

>Пропущеные "{}" коих один-два-три никак нельзя сравнить с пропусками чего-то в тонне невидимой, но значимой индентации

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

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

>неоконченном коде найти все начала и концы всех затронутых под-блоков будет посложнее

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

>каким образом образ длины пробела в 15 сантиметров (а не 12 или 16) распознаётся мозгом лучше, чем 5 скобок

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

>Я же говорю, эта задача неопределена. Математически, алгоритмически.

>В терминах дифф не спроста есть лишь удалённые и добавленные строки

Интересно, и как это авторы питона и ещё десятка языков научили комп определять количество пробелов в начале строки, а авторы диффа - не смогли. Неспроста это. Видать, алгоритм подсчёта пробелов в начале строк есть задача, доступная только "Мудрецам, Пишущим Компиляторы".

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от Led

>Маладец, умеешь обрезать посты там, где тебе удобнее

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

>А ты не знал, что в большинстве нормальных

А ты не заметил, что я ни слова не сказал про остальные языки?

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

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

Я понял, что ответа на неубодный вопрос (на ккоторый ты сам себя "загнал") от тебя не будет.

>А ты не заметил, что я ни слова не сказал про остальные языки?

Да нет, это ты сказал и не заметил. Или сделал вид, что не заметил:)

Led ★★★☆☆
()
Ответ на: комментарий от DonkeyHot

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

Раз ты меня отсылал к спекам, то возможно знаешь, что в обшем случае парсинг кода Питон вовсе не тривиален (многостроковые тексты, continuation lines, синтаксис вложенных данных и другое). Для того, чтобы сделать парсинг твоими объектами, надо компилятор (а также умный редактор) языка написать. И ты это можешь сравнивать с простой конкатинацией стрингов кода в языках с научно-полноценным синтаксисом. Стыдно.

> Спорим, ты научился выстраивать кубики в ряд намного раньше, чем считать до пяти?

В ряд, или в пять строго паралелльных рядов, да ещё и с сохранением неких строгих двухмерных правил? Я и до сих пор этого не умею, я же не машина с кульманом вместо рук. И что мне полагается как выигрыш в споре?

> Читай внимательно. [...] Вывод - он работает неправильно относительно рассматриваемых данных.

Читай ешё внимательней. он работает неправильно лишь для Питона, а для нормальных языков работает правильно, какие бы опции не использовать.

> Сколько блоков открыто в тексте {"{{{{{{{"} ? А если скобка спряталась за правым краем экрана в "nowrap" режиме редактора? А если она "психологически" невидима - спрятана между 2мя регекспами с кучей "{/;}"? Тщательнее нужно.

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

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

> То ли дело в питоне - отступ не изменился - блока нет.

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

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

> В "стандартном" оформлении используется 4 пробела, т.ч. 3 условия вполне вставляются.

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

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

> Михалыч, не тормози. В любом недописаном питонском коде конец блока есть (:пока ты не начнёшь генерировать его в хаскелевых бесконечных строках:)

(Кстати, пропустил ранее твоё замечание про Haskel. Так вот, в этом языке отступы совсем не так маразматичны как в Питоне, да они и не являются обязательными, можно всё и без них сделать, посему не надо Хаскель приводить в поддержку Питона.)

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

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

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

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

> То же действие с питоном. Убираем в любом месте пробел. Парсер чесно ругается на исправленой или следующей за ней строкой.

Враки, не ругается он. Тебе в середину треда:

http://www.linux.org.ru/jump-message.jsp?msgid=1956779#1969536

> Таким образом нужно найти только начало и конец внешнего - точно так и в случае со '}'.

Ну я же с тобой честно как с образованным общался, зачем же ты меня так подводишь? :) Повторяю, точки конца блока в Питоне нет. Совсем. 1) Физически: то, что ты считаешь концом блока n может также быть концом блока n-1, напрочь отсутствует информация. В случае же, когда на каждый конец блока имеется "}", никакой информации не отсутствует. 2) Логически: в синтаксисе нет знака для намеченного (не путать с физическим) конца блока.

> Это очень просто. Вменяемые программисты [...] правому краю экрана [...] периферийное зрение [...] чёрные пятна [...] "фокусной" строкой. Потому распознаваемый образ - это не длинна пробела а вертикальная линия, прорисованая левыми пикселями первых не-пробельных символов. Считать скобки _труднее_.

Я всё же рискну остаться при своём мнении. Считать, один-два-три, полегче будет чем по чёрному пятну слева неправильной формы без линейки и без 100 грам пытаться догадаться о структуре кода на глаз.

> Видать, алгоритм подсчёта пробелов в начале строк есть задача, доступная только "Мудрецам, Пишущим Компиляторы".

А ты не знал? Да и ценность умения diff правильно парсить синтаксис Питон на блоки невелика в общем случае.

> Есть подозрение

Советую поближе разобраться с алгоритмом (не обязательно по исходникам на C; я изучал по Algorithm::Diff, да и самому приходилось писать модули для парсирования и манипуляций над выводом diff), тогда возможно у тебя будут более здравые подозрения. Я же объяснял в чём неопределённость твоей задачи.

mihalych ★★★
()
Ответ на: комментарий от Led

>Я понял, что ответа на неубодный вопрос от тебя не будет.

Нет, я честно не понимаю, что ты имеешь ввиду. Вернёмся к первоисточнику( http://www.linux.org.ru/jump-message.jsp?msgid=1956779#1988277 ):

>А если строка python-кода за-wrap'илась во "warp" режиме редактора? или при печати?

Про редактор я ответил.

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

>Сразу получаешь рак мозга и убиваешь себя ап стену?

далеко. Этот вопрос мне неудобен?

>Да нет, это ты сказал и не заметил

Цитату в студию( вот это, кажется http://www.linux.org.ru/jump-message.jsp?msgid=1956779#1988323 ):

>И, кстати, в питоне не обязательно писать строки такой длинны - () вроде не отменяли.

где тут хоть слово про другие языки?

DonkeyHot ★★★★★
()
Ответ на: комментарий от mihalych

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

1. Достаточно парсера. 2. Достаточно подключить готовый. 3. Умный редактор и перлу не помешает - у меня почему-то всегда при попытке написать перловую программу, обрабатывающую текст, структурированый {}-ми вим с ума сходит.

>И ты это можешь сравнивать с простой конкатинацией стрингов кода

Не могу. В первом случае я буду работать с тем, чем программа на самом деле является, и не буду иметь ошибок, связаных с "наткнулся на непредусмотренную синтаксическую конструкцию". Во втором мне придётся заниматься угадыванием медода склейки: "$1;$2" или "$1($2)" или "$1 {$2}" или "$1\n$2"(для <<EOF) или ещё как - синтаксис "в языках с научно-полноценным синтаксисом" тоже редко бывает тривиален.

>>Сколько блоков открыто в тексте {"{{{{{{{"} ? >Тут имеем девиз Перла

Тут имеем михалыча, пойманого на лжи. Ты утверждал, что

>Все видимые '{' и '}' определяют границы видимых блоков. Не видишь '{' и '}' - нету и новых блоков, ...

Оба утверждения ложны.

>Впрочем, если мы рассматриваем блок на 7-ом уровне

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

>>отступ не увеличился - блока нет >(это утверждение неверно)

Либо ты показываешь, как в питоне открыть блок без увеличения отступа, или ты опять соврал. "if a: b" в одну строку не зачту, т.к. блок тут же и закрыт, т.ч. на понимание места окружающего текста не влияет.

>когда отступ уменьшился

Я написал то, что написал, т.е. ничего. Думаешь почему? "Я отвечаю за свои слова" :)

>... есть "{", но нет "}", ... работать с нормальным синтаксисом удобно ... видно в каком месте тебя прервали

Да ну. "a { b { c { d { e } f } g } h". Давай алгоритм поиска "где прервали". IMO это может быть любое место в диапазоне (e-h], а если учесть возможность удаления "отладочного if-а" с конца - то и (a-h].

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

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

>Враки, не ругается он

Ага. Изменим условие эксперимента таким образом, чтобы парсер не ругался. Что изменилось? Теперь обоим экспериментаторам нужно вычислять неправильный блок по поведению программы - питон уже "не хуже". Нужно ещё раз изменить условия - давай у питона уберём выделения всех блоков, а у перла одного. Ура! Наконец-то! Мне придётся понять всю программу, а михалычу только порядка 70%.

>Повторяю, точки конца блока в Питоне нет. Совсем.

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

>то, что ты считаешь концом блока n может также быть концом блока n-1

Может. И в чём проблема? Не получается поставить курсор? Ты уверен, что хочешь именно этого? Напиши pass.

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

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

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

> > Неправда. Помогут и ещё как. Все видимые '{' и '}' определяют границы видимых блоков. Не видишь '{' и '}' - нету и новых блоков

> Оба утверждения ложны.

Ну ты бы спросил что ли, если не понял, что я имел в виду. Ты выше сказал явную глупость, что в случае длинных блоков, '}' не помогут. Если всего блока не видно на экране, и в таком случае ничего нельзя сказать о творящемся вне видимости, то из этого никак не следует, что '}' никак не помогут в понимании той части кода, которая полностью видна. Помогут; ты будешь точно знать количество ново-открытых и закрытых блоков на полностью видимой части, что неверно в общем случае с Питоном.

Дабы избежать дальнейшего недопонимания, я никогда не говорил о редакторах или принтерах, которые отрезают при выводе концы строк, или об окне редактора сдвинутом по горизонтали (хотя и тут, то что я сказал остаётся верным, только менее актуальным). В случае же, когда строки загибаются ("cat program" или "less program"), питоновский код и вовсе нельзя распарсить на глаз. Как ни крути, синтаксис блока, использующий "{" и "}" намного читабельней и здравей.

> Давай алгоритм поиска "где прервали".

Легко. :) Прервали там, где курсор стоит. :-) Я про то, что видно, что прервали, потому как начало есть, а конца нет. А в Питоне такого не видно, потому как синтаксис убог и не поддерживает обозначение логического конца блока.

> Вот ещё одно преимущество питонского синтаксиса - он "стимулирует" делить код на компоненты, умещающиеся на экран, что полезно читающему.

Не стимулирует, а заставляет. Очень даже противоположные вещи. Это как если бы о роботе, который заставлял бы хозаина ровно в 7:00 кушать (не хочешь, заставим), сказали бы, что он стимулирует своевременное питание. И не важно, что хозяин уже поел, или сегодня лёг поздно и спит, или сейчас не в настроении, или наоборот, занят с любимой.

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

>>>отступ не увеличился - блока нет >(это утверждение неверно) ... когда отступ уменьшился

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

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

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

Что же никто так и не разоблачил такие ошибочные доводы? Вместо этого слышал нападки и предложения заменить мои реальные сценарии.

> В более точной формулировке (если позаменять всякие "никак" "всегда" и прочие кванторы на более правильные) ты был бы во многих местах прав - но тогда доводы стали бы звучать гораздо слабее.

Думаю, использование абсолютного языка, чтобы подчеркнуть фундаментальность проблем, в данном случае законно. Неужели доводы прозвучат слабее, если я скажу "никак, в общем/моём случае" или "всегда, хотя существует костыль для обхода"?

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

Изменим условие эксперимента, чтобы число проблем Питона O(N) было равным числу проблем нормального синтаксиса O(1). Что изменилось?

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

Ложь, ложь, ложь. Везде не так; везде лучше, чем в Питоне. В любом питонском коде блоки _закрыты_, потому как в Питоне нет понятия конца блока. А в других языках такое понятие есть, и если в коде нет соответствующего "}", то блок _не закрыт_. Как же можно говорить, что "так же везде"?

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

Когда нет конца блока? Когда нельзя с блоком оперировать как с единицей, не боясь её поломать? Ты и вправду не в состоянии понять убогости синтаксиса в котором нет явных блоков, а всё держится исключительно на индентации? Ну тогда тебе хоть 100 реальных проблем приводи, не поможет, у тебя как видно сценарии другие. Младенец тоже моего стремления ходить на работу не поймёт, ведь кормят и поят по рассписанию и по первому плачу. В чём проблема?

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