Здравствуйте, Сергей Губанов, Вы писали:

СГ>Всё предельно просто: читаете символ, смотрите в таблицу что он обозначает, вот и всё. Никаких заглядываний вперед, ни какой контекстной зависимости. Всё элементарно.

А теперь скажи, что эта программа делает.

Здравствуйте, jedi, Вы писали:

Д>>

Д>>00000000: 4D 5A 90 00 03 00 00 00 │ 04 00 00 00 FF FF 00 00
J>...
Д>>00000250: 13 30 04 00 6F 00 00 00 │ 00 00 00 00 02 14 7D 05

J>PE файл?

он самый

Здравствуйте, jazzer, Вы писали:

J>Ты что, правда, не понимаешь?
J>Ты же кандидат наук, ну не верю, что ты совсем не соображаешь

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

Здравствуйте, VladD2, Вы писали:

VD>Опять таки возможно. Но причем тут Губановское утверждение о том, что простую LL(1)-грамматику проще читать человеку?

Я имел ввиду связь между иерархией Хомского и сложностью понимания языка. Т.е. мне казалось, что вопрос стоял гораздо шире. Относительно же утверждения про LL(1)-грамматику, то здесь, вероятно, есть доля истны. Число связей, в сравнении с КС-грамматикой без ограничений, ограничено. Ну например, неоднозначные грамматики не могут быть LL(1), уже много для легкости понимания выигрывается. Согласен, что человек — не парсер, и процесс чтения текста им, это совсем не то, что процесс чтния текста машиной. Мой руководитель любит говорить, что если для передвижения человек изобрел колесо — свой способ, которого нет в природе, то для чтения были изобретены порождающие грамматики — метод чтения, которого нет в природе. Иначе говоря, порождающие грамматики — это этакое колесо в линвистике. Но, вот оказывается, что иерархия грамматики отражает синтаксическую сложность структуры языка. Как человек ее в себе держит и какие процессы протекают у него во время чтения, мы сказать не можем. Но, мы можем сказать несомненно, что сложность вместе с иерархией увеличивается. В случае с LL(1)-грамматиками связь, конечно, очень тонкая и не столь ощутимая, здесь бОльшую роль играют другие факторы: адекватное выражение синтаксических конструкций графически, связь с программисткой традицией, обозначение ключевых слов и т.д. Вот, например, введение в язык оператора цикла с параметром: for( ; ; ) {}. Ну кто может жогадаться, что третья конструкция должна выполняться ПОСЛЕ исполнения тела цикла? Дя человека гораздо естественнее было бы что-то типа for( ; ) {}(поститерация). Но мы воспринимаем сейчас эту неестественную конструкцию как само собой разумеещуюся. Размещение указателя на конструкцию в заключительной метке блока "end метка" традиционно решается форматированием и не засоряет код программы мусором. В общем, Оберон кажется сложнее для чтения именно из-за противостояния сишной традиции, которая есть, на смаом деле, традиция программисткого сообщества. И здесь, конечно, сложность грамматики отходит на второй план. Но, если ставить вопрос обощенно, то несоменно, при прочих равных условиях, язык, определяемый LL(1)-грамматикой, читать легче, нежели язык, определяемый КС-грамматикой без ограничений.

Здравствуйте, Sergey J. A., Вы писали:

SJA>Здравствуйте, cranky, Вы писали:

SJA>>>Да. Пожалста. Вот вам пример на BF. Граматики под руками нет, но думаю она вполне простая.
SJA>>>Что программа делает думаю объяснять не надо ? Ведь всё хорошо читается ?

C>>[...]

C>>Э-э, вопрос этики?

SJA>Э-э... Не понял вопроса...

смотрим сюда

Автор: _DAle_
Дата: 24.05.05

потом сюда

Автор:
Дата: 25.05.05

fc /b

Здравствуйте, mefrill, Вы писали:

M>Но, если ставить вопрос обощенно, то несоменно, при прочих равных условиях, язык, определяемый LL(1)-грамматикой, читать легче, нежели язык, определяемый КС-грамматикой без ограничений.

Человек действительно НЕ читает текст слева направо, так же как и не читает справа налево — он читает сразу целыми кусками, переходя от целого к деталям. Во всяком случае, человек, который не является начинающим в чтении.
Поэтому значение имеет только узнаваемость отдельных конструкция языка. Которая абсолютна ортогональна величине значения k в LL.

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, jazzer, Вы писали:

J>>Ты что, правда, не понимаешь?
J>>Ты же кандидат наук, ну не верю, что ты совсем не соображаешь

Д>Прошу никого не воспринимать мое высказывание как переход на личности, но...
Д>У нас в фирме работали два доктора наук в разное время... (скажу сразу, что недолго работали). Оба — совершенно невменяемые :xz: Боюсь, что в нашей стране это становится тенденцией.

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

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

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Сергей Губанов, Вы писали:

SJA>>Да. Пожалста. Вот вам пример на BF. Граматики под руками нет, но думаю она вполне простая.
SJA>>Что программа делает думаю объяснять не надо ? Ведь всё хорошо читается ?

SJA>>

>>>+>>+++++>>++>>+++>>+>>++++++>>++>>++>>++>>+++++>>+>>++++>>

СГ>....
СГ>

СГ>Конечно она легко читается. Вот пожалуйста:

...

СГ>Increment the byte at the pointer
СГ>Increment the byte at the pointer
СГ>...
СГ>и т.д.

СГ>А что, у Вас были какие-то проблемы с парсингом этого выражения?

Ну, раз никаких проблем у вас с этим кодом нет, то что он делает ? Думаю это несложно сказать, раз всё так просто читается ?

Здравствуйте, VladD2, Вы писали:

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

С этим абсолютно солидарен.

VD>А вот как раз LL(1) тут ни на что не влияет.

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

VD>Человек не компьютер. Он на уровне подсознания существо параллельное. Мы не читаем поток символов слева на право. Мы даже не читаем отдельные символы. Мы воспринимаем слова целиком и даже объеденяем их в предложения и абзацы. Мы можем даже не заметить мелких ошибок (иначе как бы вы все тут меня читали ), так как наш мозг просто отбрасывает их в следствии не существенности.

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

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

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

Вношу изменения в свой тезис: "Чем проще грамматика тем легче читать/писать текст". Для компилятора — это так (без компромисов), но для человека есть по крайней мере еще два фактора которые необходимо учитывать.

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

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

Вывод:

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

Здравствуйте, Дарней, Вы писали:

Д>У нас в фирме работали два доктора наук в разное время... (скажу сразу, что недолго работали). Оба — совершенно невменяемые Боюсь, что в нашей стране это становится тенденцией.

Ага, эти ученые, они же просто придурки все, сумасшедшие. (крэзи саенсист)

Здравствуйте, VladD2, Вы писали:

E>>А вот это не всегда так. Вот наглядный пример: Re: boost::multi_index + boost::tuple

Автор: qube
Дата: 15.08.05

-- конструкции самые, что ни есть, высокоуровневые (имхо), а вот разобраться в:
E>>

E>>typedef multi_index_container< my_tuple,
E>>   indexed_by< ordered_non_unique< tuple_element_extractor<my_tuple, 0> >,
E>>               ordered_non_unique< tuple_element_extractor<my_tuple, 1> >,
E>>               ordered_non_unique< tuple_element_extractor<my_tuple, 2> >
             >>>
>>> my_container;
E>>

E>>с ходу далеко не у всех получится.

VD>Это пример эмуляции пдобных конструкций. Если бы они были именно конструкциями языка, и не содержали много лишнего, то читаемость была бы куда лучше.

VD>Сравни к примеру работу с функциями высшего порядка в С++ и в любом ФЯ. Да что там ФЯ? Даже в C# 2.0 работа с ними выглядит прекрасно. А в С++ из-за эмуляции все превращается в кошмар.

Необорот, это сама по себе высокоуровневая конструкция, которая дает короткий псевдоним (my_container) сложному типу, а именно -- контейнеру, элементами которо являются tuple (с именем my_type), поддерживающий три индекса: по каждому из элементов tuple в отдельности. Думаю, что для предоставления такого контейнера на C# или Java пришлось бы попотеть гораздо больше.

Но вот читабелность такого выражения имхо, оставляет желать много лучшего.

Здравствуйте, Дарней, Вы писали:

Д>Поэтому значение имеет только узнаваемость отдельных конструкция языка. Которая абсолютна ортогональна величине значения k в LL.

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, mefrill, Вы писали:

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

VD>Пример катит, так как Губанов делал свои утверждения на базе LL(1) грамматики. РВ как раз можно описать LL(1)-грамматикой.

M>> Трудность в тех примерах, которые ты привел, заключается просто в отсутствии навыков чтения РЕ.

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

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

VD>В EBNF тоже нет. Но это ничего не менят. Главная разница в том, что в EBNF нам есть за что зацепиться. Мы можем выделить понятийные сущности в правила. Отделить пробелами части. Выделить участки грамматики которые яыляются чистыми образцами и части которые являются использованием правил.

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

VD>При некотором опыте и БрэйнФак можно привыкнуть читать. Только у нас разговор не о возможностях человеческого мозга адаптироваться к самым бредовым извращениям. А о простоте восприятия и о том, от чего она зависит.

Здравствуйте, VladD2, Вы писали:

VD>В EBNF тоже нет. Но это ничего не менят. Главная разница в том, что в EBNF нам есть за что зацепиться. Мы можем выделить понятийные сущности в правила. Отделить пробелами части. Выделить участки грамматики которые яыляются чистыми образцами и части которые являются использованием правил.

Не совсем понял, причем здесь EBNF? Что мы сравниваем, легкость чтения EBNF и РВ? но, какое тогда это отношение имеет к осуждаемому вопросу?

Здравствуйте, mefrill, Вы писали:

M>Ага, эти ученые, они же просто придурки все, сумасшедшие. (крэзи саенсист)

нет, не сумасшедшие

ПК>>Регулярные выражения описываются регулярной грамматикой. Еще проще чем LL(1). Читаются очень нелегко, если нет соответствующего навыка.

СГ>Ну и где эти контр примеры? Давайте же, приводите текст на регулярном языке.

СГ>"+123456789E-64" — такой текст сложен?

СГ>"+7 (1234) 63-74-72" — а может такой текст сложен?


Это не текст "программы" на регулярных выражениях. Это — данные для такой программы. А вот программа на РВ, обрабатывающая такие данные, даже такие простые данные, уже будет на грани непонимания.

Так, для проверки телефонного номера в Великобритании:

Данные: (5-изначный код) (6-изначный номер)

Программа: /^\d{5} \d{6}$/

Усложняем. Находим все HTML тэги в документе:

Данные: <TAG[^>]*>(.*?)</TAG> (запись частично использует РВ)

Программа: <([A-Z][A-Z0-9]*)[^>]*>(.*?)</\1>

Ну и на закуску проверка е-mail'ов:

Данные: e-mail по RFC 822

Программа (неполная): /^([A-Z0-9]+[._]?){1,}[A-Z0-9]+\@(([A-Z0-9]+[-]?){1,}[A-Z0-9]+\.){1,}[A-Z]{2,4}$/i

Ну и под конец — грамматика регулярных выражений

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Вношу изменения в свой тезис: "Чем проще грамматика тем легче читать/писать текст". Для компилятора — это так (без компромисов), но для человека есть по крайней мере еще два фактора которые необходимо учитывать.

<...bla-bla-bla поскипаны...>

СГ>Вывод:
СГ>

СГ>Сделай грамматику меньше и проще на столько на сколько это возможно, но не меньше и не проще чем это необходимо для возможности (разумного) форматирования текста согласно вкусам и предпочтениям человека.

На восприятие текста программы влияет намного больше факторов, чем здесь упомянуто. И простота/сложность грамматики вообще не имеет значения, когда мы хотим понять _смысл_ программы. Еще сложнее, когда мы пытаемся проанализировать программу и представить себе, чем она нам грозит.

Например, возьмем абстрактное выражение:

a = b + (c - d)/2;

Очевидно, что оно описывается весьма простой грамматикой.

Понятен ли нам его смысл?
Вряд ли, т.к. не известно, что такое a, b, c, d.
Предположим, что это объекты каких-то классов.

Стало понятнее?

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

Как обеспечить гарантию безопасности исключений для этого выражения?
А при наличии side-эффектов?

---

Блин, Сергей Губанов просто монстр какой-то! Целая ветка для того, чтобы убедить его в абсурдности предположения "Чем проще грамматика тем легче читать/писать текст". И все без толку.

Иконка "харакири" есть в планах RSDN Team?

Здравствуйте, AndreyFedotov, Вы писали:

AF>Видишь ли. Ты сам жульничаешь. Разберём твои же примеры:
AF>Ты ведь пишешь 12345.6787E-26, а не .00000000000000000000000000123456787
AF>Аналогично пишешь "+7 (123) 45-67-89", а не +7123456789, а ведь грамматика стала ещё проще!
AF>Но ведь про то, что читать стало легче ты, надеюсь, утвержать не будешь?

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

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

Здравствуйте, eao197, Вы писали:

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

Возможно это так, но мне они не известны. Если они известны Вам, то будьте так любезны, сообщите их пожалуйста.

E> И простота/сложность грамматики вообще не имеет значения, когда мы хотим понять _смысл_ программы.

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

E>Блин, Сергей Губанов просто монстр какой-то! Целая ветка для того, чтобы убедить его в абсурдности предположения "Чем проще грамматика тем легче читать/писать текст". И все без толку.

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

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