В Python есть оператор ';' И конструкция вида a=1; if a: pass; b=2 вполне себе легитимна на одной строке

>Есть видимые символы

Нет видимых символов. Вообще. Есть видимая при определённых методах отображения символов интерпретация. Потому

>Нормальный язык не может задействовать их в своем синтаксисе

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

Пора ехать на работу - остальное потом.

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

>если я тебя женщиной назову, ты из за этого пол поменяешь?

Угу. Поговорим о реализации структур и классов в С++? Может, там тоже классов нет, а есть только указатель this и структура с приватными данными?

В PERL __есть_классы__. Они __реализованы__ посредством ссылок и хешей. Но классы, наследование и интерфейсы в PERL __есть__.

> сам то понял что сказал?

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

угу, см. perlobj:

1. An object is simply a reference that happens to know which class it belongs to.

2. A class is simply a package that happens to provide methods to deal with object references.

3. A method is simply a subroutine that expects an object reference (or a package name, for class methods) as the first argument.

>Напиши два уровня if-else вперемежку с while на одной строке

line='if True:\n if True:\n print "Ok"\n else:\n while True:\n print "Not Ok"\nelse:\n print "Ok again"'

А вообще, пока ехал понял вот что(применяя идеи Раскина про дизайн интерфейсов - т.к. синтаксис языка _является_ интерфейсом для программера):

Многие синтаксические элементы (в том числе начало/конец блока({}), конец выражения(;), "операторы подстановки"($%&*), '\' для продолжения на следующей строке) - _не_ _имеют_ отношения к обьектам решаемой программистом задачи. По этой причине для сознания любого достаточно опытного программиста они будут _невидимы_, к.т. локус внимания оного прикладная задача, а не синтаксис языка.

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

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

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

> в грамотно спроектированом синтаксисе/интерфейсе эти символы _должны_ быть невидимы.

нифига они тебе не должны

>_не_ _имеют_ отношения к обьектам решаемой программистом задачи

это ты мосчно задвинул, жаль только что мимо тазика

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

отсюда вывод что "это" удобно только кучке маргиналов. точка

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

Закрой рот, и ты сможешь открыть глаза немного шире. Питон в этом деле далеко не единственный, не первый и не лучший.

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

И ещё - как показали комменты, никто из противников perl c perl не знаком совсем. :))

>>читайте мануал

>Спасибо, я там уже был - лучше по хаскелю почитаю:-)

"быть" мало - надо бы почитать:)

>Тормозишь. Всем пофиг как в твоём редакторе выглядят пробелы в началах строк. Лишь бы в файле было правильно.

Не Щ-editor мне не нравится, а в других редакторах не получается заставить вместо пробела рисовать Щ (и только если пробелы - ведущие).:)

>Мосье накогда не видел не-текстовых исходников? Мне приходилось.

Я ж и говорю - поподробнее, плиз:) Потому как я - не видел:)

>Кроме того, даже поддержка plaintext-а себе рознь. Часто ли ты пишешь в редакторе, не умеющем (например) искать соответствующие скобки?

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

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

Что, уже каникулы начались? Марш в школу учить что такое синонимы и т.п.!:)

>Многие синтаксические элементы (в том числе начало/конец блока({}), конец выражения(;), "операторы подстановки"($%&*)

Про оператор постановки - бред, потому как ты смысл его "неасилил"

>Про оператор постановки - бред

А по сути?

> line='if True:\n if True:\n print "Ok"\n else:\n while True:\n print "Not Ok"\nelse:\n print "Ok again"'

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

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

>А по сути?

А по сути - осилить смысл оператора подстановки и понять чем отличется

a=b (например, в том же С или python)

и

a=$b (например, в perl или tcl)

>a=$b (например, в perl или tcl)

Сорри, в tcl конечно же

set a $b

:)

> В Python есть оператор ';' И конструкция вида a=1; if a: pass; b=2 вполне себе легитимна на одной строке

То есть по-твоему я могу писать такое:

if ready: value = 1; if sent: sent = 0; else: value = 2

где "else" относится к первому "if", или всё таки не могу?

>Круто и очень читабельно.

Если ты выведешь его клиенту для "прочтения" в любом приличном текстовом читателе его читаемость сильно повысится. Попробуй сказать print line - он отлично читается.

>этот пример абсолютно не проходит компиляцию, И мы прекрасно знаем почему

Потому что я забыл поставить "preformatted text" при отправке текста. Кто мне виноват?

>таких как форумы

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

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

В форумах с правильной обработкой переданого - тоже:-)

По правде говоря, текст программы есть сложная структура(дерево, что ли) записаная с использованием определённого "кода". Естественно, в средах, выбрасывающих часть этого кода, передача невозможна без определённого шаманства. Для питона внутри html-я дополнительно нужен <pre>.

Кстати, если ты проделаешь тот же трюк с форумом с текстом любой программы, использующий для каких-то целей несколько пробелов внутри строки, она так же невосстановимо испортится. Но ты об этом узнаешь не по ошибке разбора, а по неправильным результатам работы. Что может быть намного хуже. Пример для C: 'char *x=" "'; x[2]=1;' в _лучшем_ случае упадёт в корку.

PS: Пример для C

Естественно, у меня всё было ОК - "x" имел достаточное количество пробелов:-)

>чем отличется a=b и a=$b

Тем, что первое компилится без ошибок?

perl -e '$b=2 ; a=$b;'
Can't modify constant item in scalar assignment at -e line 1, at EOF
Execution of -e aborted due to compilation errors.

>Сорри, в tcl конечно же

А вот в tcl совсем другие $-ы.

>perl -e '$b=2 ; a=$b;'

>Can't modify constant item in scalar assignment at -e line 1, at EOF

>Execution of -e aborted due to compilation errors.

Безнадёжный случай:) Что такое ОПЕРАТОР в языке - для тебя непостижимо :(

>Безнадёжный случай:) Что такое ОПЕРАТОР в языке - для тебя непостижимо

Безнадёжный случай:) Что такое синтаксис языка - для тебя непостижимо :-)

>>Безнадёжный случай:) Что такое ОПЕРАТОР в языке - для тебя непостижимо

>Безнадёжный случай:) Что такое синтаксис языка - для тебя непостижимо :-)

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

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

То есть всё-таки код намертво привязан к редактору, и отдельно от него обсуждению не подлежит. Понял. А к какому именно? Слышал, что Visual Studio хорош, и кнопочки там красивые.

> Попробуй сказать print line - он отлично читается.

Значит просто код текстом я не могу передать, его надо кодировать перед посылкой _любой_ программы. Хороший себе бинарный язык... Кстати, если бы ты использовал "\t" наряду с "\n" вместо начальных пробелов в своём примере, то хотя бы одной проблемой (из трех) было бы меньше.

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

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

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

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

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

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

Зачем же так мучать питониста (не ругайте пианиста, он играет как может). Тем более, что в контексте данной новости ты не совсем прав. В Perl 5, $ или @ с последующим var[] или var{} выполняют некую функцию, а в Perl 6 - уже нет. Скалярный или списочный контекст определяется по другому окружению, а иногда и вовсе откладываются во времени. Правда операторы приведения ${ ... }, @{ ... }, %{ ... } остались.

Наверное, более правильно всё же назвать $@% частью variable namespace, когда речь идет о $var, а не операторами.

Я кажется догадываюсь, какой редактор лучше всего использовать для текстов программ на пайтоне: что-то типа Excel или OOCalc (одинарный лгический отступ - одна ячейка) - значущее форматирование не потеряется ни в HTML формате, ни даже в CSV:)))

> Попрограммируйте на питоне - в художественной литературе начнёте пробелы инстинктивно подсчитывать

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

>Наверное, более правильно всё же назвать $@% частью variable namespace, когда речь идет о $var, а не операторами.

Вот с www.perl.com:

"Values are usually referred to by name, or through a named reference. The first character of the name tells you to what sort of data structure it refers."

"Scalar values are always named with '$', even when referring to a scalar that is part of an array or a hash. The '$' symbol works semantically like the English word "the" in that it indicates a single value is expected."

"Entire arrays (and slices of arrays and hashes) are denoted by '@', which works much like the word "these" or "those" does in English, in that it indicates multiple values are expected."

В принципе, признаю, что немного прогнал: в perl $ - не совсем то же самое, что в sh/bash/tcl:)

>Значит просто код текстом я не могу передать

Который раз повторяю: ты не можешь его передать средствами, искажающими его синтаксические конструкции. Таких распространённых средств аж 1(класс) - всякие sgml-и (возможно я что-то упустил, например твой вим с s/ \+/ /:-)

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

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

Это проблема _не_ языков, а писателя обработчика. Да, indent-синтаксис добавляет 1 проблему их писателям - необходимость оставить неизменными 3 символа. Совершенно неподьемная задача;-)

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

Известно, что внимательному слушателю длина пауз сообщает определённую информацию.

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

1. Обоснование обратного было выше. 2. Несколько пробелов в _данных_, которые ты назвал "стрингами" - вполне корректное требование.

>ни один из своих двух фатальных дефектов

Есть подозрение, что эти дефекты фатальны для каких-то других языков:-) - они играют не последнюю роль в росте популярности питона.

>оператор не просто так "нарисован", а выполняет какое-то действие

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

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

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

Немножко непривычно осознавать, но это описание из документации не верно для Perl 6. Например, эта строка, одинаковая для Perl 5 и 6:

my $a = [3, 4]; my @a = (3, 4);

аналогична следующей:

my $a = (3, 4); my @a = [3, 4];

Я не шучу. И все операторы такие как [] работают над этими $a и @a идентично:

$a[1] == 4; @a[1] == 4; ref($a) eq '::Array'; ref(@a) eq '::Array';

$a.join(', ') eq @a.join(', '); +$a == +@a;

Может занять некоторое время, чтобы произошел ментальный сдвиг. Просто абсолютно всё объекты. И $а может в себе содержать объект любого типа, Str, Array, Hash, Int, Pair, Person. А @а может содержать лишь объект Array, %а - лишь Hash.

> Таких распространённых средств аж 1(класс) - всякие sgml-и (возможно я что-то упустил)

Ты много чего упустил. Все публикационные языки, а не только sgml игнорируют повторяющийся whitespace, скажем TeX, Postscript. Это же относится к неэлектронным обработчикам художественного текста (печатные станки), там вообще нет литер для невидимых символов. Повторяющийся whitespace игнорируется во всех текстовых коммандно-ориентированных протоколах, начиная с коммандной строки шелла, и заканчивая smtp/ftp/irc.

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

> 1. Обоснование обратного было выше.

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

> Известно, что внимательному слушателю длина пауз сообщает определённую информацию.

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

> играют не последнюю роль в росте популярности питона

Так я же с этим не спорю. Для тех, кому не нужна гибкость, Питон может и сгодится.

>советую автору сообщения ознакомиться с perl

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

Так что советую автору начать немножко думать.

>Питон нагло нарушает общепринятые нормы...Повторяющийся whitespace игнорируется во всех текстовых коммандно-ориентированных протоколах

Предназначение кода программ несколько отличается от "быть напечатаным". Также питон/хаскель/оккам/прочие не является командно-ориентироваными протоколами.

Так почему их синтаксис должен соответствовать нормам, принятым в этих отраслях?

>программа на Питон - никоим образом нет

А вот тут неправда твоя. Контрпримеры: <pre> достаточно для передачи в html. Хаскель пользуется отступами почти так же, и при этом отлично встраивается в TeX-овые документы(т.н. literate haskell).

>Для тех, кому не нужна гибкость, Питон может и сгодится

А с этим я не спорю:-). Мы же не о питоне спорим.

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

>Все публикационные языки, а не только sgml игнорируют повторяющийся whitespace, скажем TeX, Postscript.

Ну, вобще-то Postscript немножко "из другой оперы" - это Forth-язык. Он не имеет ничего общего ни с языками разметки (HTML/XML/SGML/TeX), ни с классическими высокоуровневыми языками, ни с форматами типа dvi,cdr и т.п.:) Ближе всего он к ассемблеру стекового процессора, хотя и не совсем ассемблер:)

>пока не наловчусь безошибочно отличать 5-и секундные паузы в разговоре от 6-и секундных.

Размечтался!:) а 0.1- и 0.2-секндные паузы не хочешь? При том что они очень важны и смысл при применении тех или других КАРДИНАЛЬНО меняется (или вобще - "не компилируется"):)

>Для тех, кому не нужна гибкость, Питон может и сгодится.

Может... Только я, в своё время, именно из-за вышеуказанных причин "отвернулся" от пайтон :(. Пока есть Tcl, ИМХО пайтон толькодля тех, кто "неасилил" Tcl. А нишу перла пайтон практически не перекрывает.

Слабенькая аналогия:)

>Предназначение кода программ несколько отличается от "быть напечатаным".

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

>Предназначение кода программ несколько отличается от "быть напечатаным".

Любишь аналогии? Как тебе такая:

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

>Любишь аналогии? Как тебе такая:

(*)Это не аналогия - это факт. Подозреваю, что всякие продвинутые IDE _парсят_ тексты и работают с ними на уровне AST-ов, откуда до кодогенерации не так уж далеко:-).

(*) я пользую вим - потому это только моё впечатление основаное на косвенной информации.

Не надоело лапшу на уши вешать:-?

>У исходного текста программ предназначения: ... быть напечатанным.

Да, и только после этого компилированым. Ню-ню...

>А выполнять вместо компилятора работу - набивать и подсчитывать символы с кодом 32

1. Компилятор не набивает пробелы. 2. Программер тоже.

Так о чём это ты?

>Слабенькая аналогия:)

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

Так что хватит #$%#$%ть, начинай обосновывать свои слова.

>начинай обосновывать свои слова.

Я-то как раз обосновываю, а ты "спрыгнул" с заявленных тобою "не plain text исходных текстов программ":)

>Я-то как раз обосновываю

Не заметил:-( Можно цитату?

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

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

>Пошел посмотрел - там есть вполне текстовое представление

И количество пробелов роли не играет?

Если интересно - примерно 800000 строк (в одном модуле) примерно такого содержания(очевидно BEGIN/END ограничивают блок - так что с пробелами всё ОК:-):

DEFINE  F50P
BEGIN
   PP = 10
   PI = 4
   PN = 464
   PL = 145
   PV = (BLONG)
<<"
00000042 00800000 00440000 00000000 0000001d 0000000a 00000002 80010509 
00002420 0000007d 00010000 00175032 395f3034 5f4a414e 5f323030 3031345f 
32345f35 33000000 06424547 494e0a00 0000292f 2a636c65 61725f62 6c6f636b 
20284e4f 5f56414c 49444154 45293b2a 2f0a6578 69745f66 6f726d3b 00000005 
0a454e44 3b000000 00000000 00000000 00000000 
">>
END

на Postscript ещё посмотри - это тоже текст программы:)

>на Postscript ещё посмотри - это тоже текст программы:)

Думаешь я не смотрел? Там почти всё понятно, в отличие от этого kalci фирмы Oracle.

>>на Postscript ещё посмотри - это тоже текст программы:)

>Думаешь я не смотрел? Там почти всё понятно

Заметь, что не менее понятно будет, если смотреть его в обычном less, не так ли (спец-эдитор не нужен для этого)?:)