Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Видишь ли. Ты сам жульничаешь. Разберём твои же примеры: AF>>Ты ведь пишешь 12345.6787E-26, а не .00000000000000000000000000123456787 AF>>Аналогично пишешь "+7 (123) 45-67-89", а не +7123456789, а ведь грамматика стала ещё проще! AF>>Но ведь про то, что читать стало легче ты, надеюсь, утвержать не будешь? AF>>То есть что ты сам делаешь? Ты сознательно повышаешь сложность грамматики, что бы повысить читаемость — улучшить восприятие твоего кода человеком.
СГ>Идея хорошая, я обязательно над ней подумаю.
Только очень надеюсь, что ты её правильно понял. Потому, как я вообще то, говорил о балансе. Доведя до крайней формы практически любую идею можно получить нечто ужасное. Ты ведь на машину Тьюринга с примитивной грамматикой не пересаживаешься, бросив любимый Оберон? И не бросаешься писать на ассемблере — который обладает более простым синтаксисом, чем Оберон, да в добавок позволяет писать наиболее эффективный код из всех возможных вариантов? Но ведь и на каком-нибудь заумном языке с навороченным синтаксисом тоже не пишешь? То есть ты просто выбрал для себя нечто среднее, компромисное, сбалансированное. Вот такой же комплексный, системный подход я тебя и призаваю применить к анализу читабельности кода.
> B>Так чтоже делает эта программа?
> Я так понял, Сергей хочет сказать, что, чем проще грамматика, тем проще понять, что написано с грамматической точки зрения. Вы же все приводите примеры с трудной семантикой, это совсем другое.
, что один язык "более удобен для чтения" на основании того, что описывается простой грамматикой, LL(1). Более того, даже пояснил, что речь идет о понимании смысла написанного. А теперь, когда ему привели множество примеров, их смысл он отказывается понимать, сводя весь анализ приводимых примеров к синтаксическому разбору.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
E>Это скорее не программы, а средства просмотра программ обепечивают.
Да. Но тем не менее если подсветка есть, то проще выделить базовые элементы и код воспринимается проще. И так везде. Даже вот лиспари умудряются код подсвечивать. И даже говорят, что мол вам не понятен код на Лиспе потому что нет подсветки.
E> На самом деле идеально, когда программа читается даже будучи распечатаной в моноширинном шрифте без каких либо ухищрений (вроде выделения отдельных лексем жирным/подчеркиванием).
Даже самый идеальный код будучи подсвеченным будет читаться еще лучше.
VD>>5. При написании которых использовались высокоуровневые операторы и функции.
E>А вот это не всегда так. Вот наглядный пример: Re: boost::multi_index + boost::tuple
Это пример эмуляции пдобных конструкций. Если бы они были именно конструкциями языка, и не содержали много лишнего, то читаемость была бы куда лучше.
Сравни к примеру работу с функциями высшего порядка в С++ и в любом ФЯ. Да что там ФЯ? Даже в C# 2.0 работа с ними выглядит прекрасно. А в С++ из-за эмуляции все превращается в кошмар.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mefrill, Вы писали:
M>Насчет сложности, мне кажется, что можно выделить две сложности: иерархическую или реляционную и, если можно так выразиться, объемную. То, о чем говорит Сергей Губанов, это иерархическая сложность, в зависимости от типа грамматики, возрастает число различных связей между сущностями языка. Даже, я бы сказал, качество этих связей. Например, такая-то строка может быть в языке только, если впереди есть семь таких же строк. С этой точки зрения Губанов прав. Есть еще сложность как количество таких связей в грамматике. Вот это объемная сложность, в автомате выражающаяся через количество состояний.
Мне кажется, что ты как и Губанов ошибашся. Только Губанов ошибается так как просто неспособен адекватно оценить реальность. А на тебя слишком сильно давлеет профессиональный опыт.
Простота и сложность восприятия человеком (а именно об этом вроде бы мы все тут говорим) определятся куда большим количеством факторов. А вот как раз LL(1) тут ни на что не влияет.
Человек не компьютер. Он на уровне подсознания существо параллельное. Мы не читаем поток символов слева на право. Мы даже не читаем отдельные символы. Мы воспринимаем слова целиком и даже объеденяем их в предложения и абзацы. Мы можем даже не заметить мелких ошибок (иначе как бы вы все тут меня читали ), так как наш мозг просто отбрасывает их в следствии не существенности.
Так же мы воспринимаем и программы. Мы не LL(1)-сканер. Мы воспринимаем придложение. Когда я вижу кострукцию:
foreach (a in list)
f(a);
то я сначала улавливаю, что это перебор коллекции. Потом я обращаю внимание на то, что за коллекция. Потом забываю об этом и сосредотачиваюсь на том что творится с каждым ее элементом. В этот момент я конечно подразумеваю, что речь идет о итерации, но я уже мысленно абстрагировался от этого.
Для меня совершенно все равно как будет записан данный код. Если он будет выглядеть так:
list.ForEach(f);
то в отличии от компилятора, я восприйму этот код точно так же, так как я выделяю главную суть кода. Я распознаю паттерн и абстрагируюсь от него.
А ведь код просто таки развернулся с точностью до наоборт. Теперь, чтобы понять смысл конструкции прийдется дочитать его до конца.
А вот если точно тот же код записать как-то так:
foreach(a ib list)f(a);
то мое восприятие резко ухудшится. А если еще выключить подсветку синтаксиса:
foreach(a ib list)f(a);
то в куче другого кода я вообще начну теряться. В то же время для LL(1)-парсера все это не существенно.
Теперь перейдем к простоте. Более простой язык не обладает теми самыми паттернами или конструкциями для их реализации. Стало быть тот же самый паттерн прийдется записать куда более громоздкой конструкцией:
IEnumerator enumList list = .GetEnumerator();
while (enumList.MoveNext())
f(enumList.Current);
или
for (int i = 0; i < list.Count; i++)
f(list[i]);
на Обероне пусть пишет Губанов. Думаю, будет еще хуже.
Так вот все это ухудшает восрпиятие человеком. По этому скорее язык обладающий более сложным синтаксимом но позвляющий более кратко и интуитивно записать конструкцию окажется для меня более понятным.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mefrill, Вы писали:
M>Ага, понял, ты имеешь ввиду язык регулярных выражений как целевой язык, а его грамматику как целевую грамматику? Но, тогда язык РЕ не описывается регулярной грамматикой, там же иерархия явная, куча вложенных скобок. По своему опыту могу сказать, что там КС-грамматика. Поэтому, пример все-равно не катит.
Пример катит, так как Губанов делал свои утверждения на базе LL(1) грамматики. РВ как раз можно описать LL(1)-грамматикой.
M> Трудность в тех примерах, которые ты привел, заключается просто в отсутствии навыков чтения РЕ.
Нет. Трудность именно в плохой читаемости. То же описание в EBNF будет читаться без запинки с теми же навыками.
M> В этом языке нет знакомых нам конструкций, типа ключевых слов, вытащенных из английского языка, и потому понятных всем.
В EBNF тоже нет. Но это ничего не менят. Главная разница в том, что в EBNF нам есть за что зацепиться. Мы можем выделить понятийные сущности в правила. Отделить пробелами части. Выделить участки грамматики которые яыляются чистыми образцами и части которые являются использованием правил.
M> При некотором опыте сформируются связи между понятием и его графическим изображением, и все будет читаться легко.
При некотором опыте и БрэйнФак можно привыкнуть читать. Только у нас разговор не о возможностях человеческого мозга адаптироваться к самым бредовым извращениям. А о простоте восприятия и о том, от чего она зависит.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
SJA>>Да. Пожалста. Вот вам пример на BF. Граматики под руками нет, но думаю она вполне простая. SJA>>Что программа делает думаю объяснять не надо ? Ведь всё хорошо читается ?
SJA>>
...
СГ>Increment the byte at the pointer СГ>Increment the byte at the pointer СГ>... СГ>и т.д.
СГ>А что, у Вас были какие-то проблемы с парсингом этого выражения?
Ну, раз никаких проблем у вас с этим кодом нет, то что он делает ? Думаю это несложно сказать, раз всё так просто читается ?
Здравствуйте, cranky, Вы писали:
SJA>>Да. Пожалста. Вот вам пример на BF. Граматики под руками нет, но думаю она вполне простая. SJA>>Что программа делает думаю объяснять не надо ? Ведь всё хорошо читается ?
C>[...]
C>Э-э, вопрос этики?
Здравствуйте, mefrill, Вы писали:
M>С другой стороны, я конечно, не знаток Оберона, но мне кажется, что Си++ сложен, если так можно выразиться, концептуально.
Ну, С++ действительно сложно воспринимать. Для сравнения лучше брать Шарп. Его граматика значительно сложее чем даже С++-ная. Но программы на нем читаются даже лучше чем на Обероне. А это уже полный парадокс если принять за правду утверждение Губанова о том, что простая LL(1)-граматика воспринимается человеком проще.
Граматика Шарпа довольно часто вообще не соотвествует LL(1). То и дело приходится заглядывать вперед и даже вставлять разные левые контексные правила.
M> Т.е. в нем "больше идей", типа обобщенного программирования и программирования времени компиляции. Эти идеи для реализации используют старый синтаксис, поэтому часто получается неоднозначность, т.е. качество (сложность) связей повышается. Точно также происходит и в естественном языке, для новых областей знания используются старые термины ивыражения, только в новом значении, которое часто тесно связано со старым. В языках, писавшихся "с нуля" подобная эволюция не прослеживается. Но, если язык удачен и принят многими в программистком сообществе, то его "эволюция" в направлении увеличения качественной сложности неизбежна.
Наверно. Но вопрос то не в этом. Вопрос в том, что человек не прасер. У него нет пробелм в заглядывании в перд. Более тог, он вообще легко и безошибочно пропускает целые части выражений. Например:
try
{
куча кода
...
}
catch (Xxx xx)
{
}
для сразу равно воспринимается как обработка исключения Xxx. У меня нет проблем в заглядывании. Я так же спокойно пропущу все параметры и посморю на тело фукнции. Или мне все равно где описывается тип возвращаемого значения функции.
В общем, мы не парсеры. И критерии применимые для оценки сложности пареров не применимы к людям.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> M> Т.е. в нем "больше идей", типа обобщенного программирования и программирования времени компиляции. Эти идеи для реализации используют старый синтаксис, поэтому часто получается неоднозначность, т.е. качество (сложность) связей повышается. <...> > > Наверно. Но вопрос то не в этом. Вопрос в том, что человек не прасер. У него нет пробелм в заглядывании в перд.
В случае C++ mefrill прав: (внешне) одна и та же конструкция может означать разные вещи, и заглядыванием вперед, в отличие от того же C#, эти неоднозначности не разрешаются.
Например:
C();
Если С — тип, то это создание временного объекта, иначе — вызов функции.
Еще:
class C;
C c(A());
Если A — тип, то это объявление функции, иначе — определение переменной.
Или:
C < a > b;
Если C — шаблон, то это определение переменной типа C<a>, иначе — вызов операций сравнения (C < a) > b.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В прошлый раз, делая это утверждение, ты так и не обосновал его. Так что лучше в качестве аргумента его не использовать...
Тебе показалось. Сравни размер граматик и даже вопрос не возникнет.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В случае C++ mefrill прав: (внешне) одна и та же конструкция может означать разные вещи, и заглядыванием вперед, в отличие от того же C#, эти неоднозначности не разрешаются.
Дык тогда о чем речь. Губанов то именно про необходимость заглядывания говорит. Мол не надо заглядвать — кода на языке читается просто. Надо — сложно.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>В прошлый раз, делая это утверждение, ты так и не обосновал его. Так что лучше в качестве аргумента его не использовать...
> Тебе показалось. Сравни размер граматик и даже вопрос не возникнет.
Это не сложность, а объем. Суть ортогональные вещи. Можно "наколбасить" регулярную грамматику, заметно большего объема, чем какую-нибудь КЗ-грамматику. От этого она станет объемнее, а не сложнее.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это не сложность, а объем. Суть ортогональные вещи. Можно "наколбасить" регулярную грамматику, заметно большего объема, чем какую-нибудь КЗ-грамматику. От этого она станет объемнее, а не сложнее.
В граматике сложность и определяется объемом. Ты же говоришь о семантической сложности.
Собственно опять таки исходим из Губановских данных.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> В случае C++ mefrill прав: (внешне) одна и та же конструкция может означать разные вещи, и заглядыванием вперед, в отличие от того же C#, эти неоднозначности не разрешаются.
> Дык тогда о чем речь. Губанов то именно про необходимость заглядывания говорит. Мол не надо заглядвать — кода на языке читается просто. Надо — сложно.
Имхо, то о чем говорит mefrill (количество "идей" и сложность связей между ними), более интересно. И упоминаемая им неоднозначность, имхо, тоже напрямую связана со сложностью чтения.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Имхо, то о чем говорит mefrill (количество "идей" и сложность связей между ними), более интересно. И упоминаемая им неоднозначность, имхо, тоже напрямую связана со сложностью чтения.
Опять таки возможно. Но причем тут Губановское утверждение о том, что простую LL(1)-грамматику проще читать человеку?
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>Это не сложность, а объем. Суть ортогональные вещи. Можно "наколбасить" регулярную грамматику, заметно большего объема, чем какую-нибудь КЗ-грамматику. От этого она станет объемнее, а не сложнее. > > В граматике сложность и определяется объемом.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>А такая регуларная грамматика читается очень легко: Берем и считываем следующий символ и ищем его в таблице ASCII символов, если находим, значит хорошо, мы поняли написанное, в противном случае констатируем синтаксическую ошибку.
Ты что, правда, не понимаешь?
Ты же кандидат наук, ну не верю, что ты совсем не соображаешь, с другой стороны, не хочется верить, что ты намеренно подменяешь предмет обсуждения с легкости понимания смысла кода на легкость его грамматического разбора.
Ты говоришь: "если находим, значит хорошо, мы поняли написанное" — так вот мы ничего не поняли, кроме того, что данный текст грамматике соответствует и компилятор не выдаст на него синтаксической ошибки.
Не более того.
Но к СМЫСЛУ написанного, к пониманию цели написанного кода тебя это не приблизит никак.
Если ты видишь выражение типа i++, ты понимаешь, что это постинкремент, но без знания того, что такое i, ты не можешь сказать о коде абсолютно ничего осмысленного.
Если ты видишь "WHILE ... DO ... END", ты можешь только сказать ,что в программе есть цикл, но это примерно соответствует ценности информации, содержащейся в знаменитой фразе "У ней внутре неонка".
Главное для языка программирования — чтобы человек понимал ОБЩИЙ СМЫСЛ написанного с первого взгляда.
И все. Понимаешь?
То же самое относится к естественным языкам: их грамматика на порядок сложнее и контекстно-зависимее любого из компьютерных языков, тем не менее человек понимает смысл написанного сразу же. Более того, он поймет даже неграмотно написанный текст, т.е. текст, который грамматике не соответствует.
Так что тип грамматики на читабельность текста программы не оказывает никакого влияния.
Разберём твои же примеры:
), так как наш мозг просто отбрасывает их в следствии не существенности.
