Здравствуйте, Курилка, Вы писали:
Д>>One man army, короче говоря. Остается только удивляться, как у него остается время на собственно разработку, при такой то активности в форуме.
К>А есть уверенность, что остаётся?
А оно и не нужно. Великая миссия просветительства неучей
Здравствуйте, Трурль, Вы писали:
К>>А я и не пытался как-либо соединить отношение следования с операцией сложения. К>>Группа — это пара { множество M, операция M*M->M } обладающая рядом заявленных свойств. Всё. Т>Но символы 2 и 5 не имеют смысла для "просто группы".
А мы родим кривую арифметику: введём отношение следования (чтобы оправдать значения 2 и 5), но операцию сложения не станем выводить из следования.
C>>>>Для того, чтобы можно было удобно изменять код (менять if/elseif на C>>>>switch, менять while на if и т.п.).
СГ>>>Должно быть, прикольное занятие. А в чем его смысл?
M>>Вам такое понятие, как refactoring известно? Или вы спазу пишете правильный код, не требующий изменений?
HB>Он сначала доказывает правильность кода строго математически...
Математически-то оно математически. А вот при написании такое иногда вылазит Вон, я ошибку в простейшем слове допустил
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, CrystaX, Вы писали:
CX>>...минимальное количество лексем?
СГ>Минимальное для базовых инструкций (IF, CASE, WHILE, ...), но, естественно, не меньше одной лексемы между идентификаторами пользователя.
Ок, тогда следующий вопрос. На кого направлена эта правильность? Для кого это правильно? Для разработчика компилятора? Несомненно. Говорю об этом как человек, принимавший участие в разработке компилятора perl-like языка.
А для пользователя этого языка? Согласитесь, Сергей, их несравнимо больше. Ведь вся современная индустрия движется в направлении улучшения usability. Примеров тому огромное множество, причем с IT даже и не связанных. Давайте сравним два участка кода (простейших), написанных на Обероне и на C:
if(x) a();
IF x THEN a END
В первом случае мне понадобилось 10 нажатий клавиш. Во втором — 15. Это не говоря уж о необходимости периодически удерживать SHIFT. То есть да, лексем в первом примере больше (8), чем во втором (5), но вот ведь беда — пользователь мыслит не лексемами, а логическими блоками (узлами AST, если угодно). Так вот, что в первом, что во втором примере таких блоков одинаковое количество. Но первый пример лучше для пользователя, так как меньше нажатий клавиш. Вот вам и критерий правильности синтаксиса с точки зрения пользователя: минимальное количество символов (не лексем!) при сохранении логической ясности.
Вы спрашиваете, как долго будет существовать такой C-синтаксис? Отвечу Вам — до тех пор, пока не придумают новый, более удачный с точки зрения минимизации символов в типовых конструкциях. Но, боюсь, в скором времени этого еще не произойдет.
Да, язык C++ с точки зрения разработчика компилятора этого языка ужасен. Но как он удобен множеству его пользователей! Да-да, удобен, иначе он давно уже был бы мертв.
Это именно то, о чем я писал в самом первом своем сообщении: "компилятор — наш раб, а не наоборот, поэтому все ок". Меня не волнует, сколько лексем придется обработать компилятору, прежде чем он выдаст рабочий код. Меня не волнует, сколько стенаний и потрясаний кулаками произвели разработчики компилятора во время его разработки. Меня волнует один единственный критерий — насколько мне удобно использовать этот язык. А удобство это напрямую проистекает из количества нажатий клавиш. Вот если бы были клавиатуры, на которых каждая клавиша — это готовая лексема, тогда, возможно, что-то изменилось бы.
Вот, собственно, и все, что захотелось сказать по данному вопросу. Если у Вас будут возражения по существу — добро пожаловать, готов обсудить.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>1) Известно, что Си-образный синтаксис использует больше лексем чем это реально необходимо. СГ>2) Известно, что стандарты оформления Си-образного кода требуют использования большего количества строчек чем это реально необходимо (чтобы читающему понятно стало где что написано).
Сергей, Вы затронули интересную тему.
В отличие от модераторов RSDN, я не считаю ее смешной.
Но мне кажется, что "количественный" аспект здесь не главный.
Предлагаю Вам расширить тему и рассмотреть некоторые "качественные" аспекты.
Эту расширенную тему можно было бы, например, назвать "Исходные тексты в Си/Си++ и Обероне".
Я набросал несколько несколько наблюдений.
Получилось примерно следующее.
1. Собственно синтаксис.
а) Соответствие структурным принципам.
В отличие от синтаксиса Модулы/Оберона синтаксис Си/Си++ не соответствует принципам структурного программирования.
Рассмотрим хотя бы циклы.
Когда программист пишет (или, что важнее, читает) на Модуле/Обероне цикл
WHILE p DO ... END
он абсолютно уверен, что перед следующим оператором после выхода из цикла выполняется условие ~p (NOT p).
Если программист читает аналогичный цикл
while (p) { ... }
на Си/Си++, он не может быть в этом уверен, т.к. внутри цикла может находиться как оператор break, так и знаменитый goto.
Соответственно, проверка корректности программы существенно затрудняется.
То же относится к циклам REPEAT UNTIL ~p и do {} whiie (p).
б) Синтаксический "оверхед".
Я согласен с Сергеем, что в синтаксисе Си/Си++ заключен значительный "оверхед".
Но таится он в основном в величине и сложности языка и его описания, а также в некоторых синтаксических деталях.
Например, в количестве уровней и запутанности приоритетов операторов.
Скажите честно: многие ли помнят таблицу приоритетов операторов Си/Си++ полностью?
И сравните это с Обероном, где всего четыре уровня приоритетов:
1) операция ~ (логическое отрицание);
2) мультипликативные операции;
3) аддитивные операции;
4) сравнения.
Остается добавить, что операции одного приоритета выполняются слева направо. И все. Что, сложно?
2. Исходные тексты Си/Си++ и документы Оберона.
Есть существенное различие в работе с исходными текстами программ на Си/Си++.
Программа на Си/Си++ — это по-прежнему обыкновенный текст.
Программа на Обероне — это документ, включающий в себя не только текст, но и множество самых разнообразных объектов.
(Причем это различие существует еще с 1980-х годов.)
ИМХО, это существенно сказывается на удобстве разработки.
Попытаюсь это обосновать.
а) Документирование программ.
Вот простой пример.
При разработке программы со сложным алгоритмом обыкновенно требуется делать ссылки на литературу: ищи пояснения в такой-то книге, на такой-то странице.
Мне же оказалось достаточно взять требуемые фрагменты (и, что немаловажно, с "картинками" ) из документа, содержащего известную книгу Кормена, Лейзерсона и Ривеста, и вставить как комментарий в программу на Компонентном Паскале прямо перед соотвествующим им кодом.
Алгоритм теперь читается и понимается легко и даже приятно.
Кроме того, благодаря тому, что все ключевые слова состоят только из заглавных букв и благодаря этому выделяются сами собой, программист может использовать цвет букв (а также размер и шрифт) по своему усмотрению для выделения особо важных фрагментов кода. Скажем, не уверен в данном коде — пометил его красным: проверить! Это очень эффективная система, т.к. цвет бросается в глаза, и такой участок кода трудно не заметить.
Напоминаю, что подобные возможности доступны в Обероне с 1980-х.
А что же Си/Си++?
б) Тестирование программ.
Надеюсь, никто не будет спорить, что надо тестировать как программы в целом, так и отдельные компоненты и подпрограммы.
На Си/Си++ тесты, как правило, хранятся в отдельных файлах и "запускаются" отдельными скриптами, которые тоже хранятся в отдельных файлах. В итоге, хранение этих вспомогательных, но необходимых файлов вырастает в целую проблему.
(Я уж молчу о той деликатной детали, что многие Си++программисты вообще не хранят тестов. По принципу: протестировал — и забыл. Если не забыл протестировать... )
На Обероне/Компонентном Паскале тесты могут храниться в самом исходном документе: после точки или в комментарии.
С помощью команд в обероновской среде можно запускать тесты для отдельных компонентов и даже отдельных подпрограмм. Для этого я помещаю тестовые команды прямо в исходном модуле, а коммандеры с исходными данными для тестов — после точки или в комментарии. Достаточно одного щелчка мыши, чтобы запустить нужный тест.
После того, как я протестировал модуль, я не убираю тестовые команды в комментарии (и уж, тем более, не удаляю их!), а прячу в складку (fold). Опять же достаточно будет щелчка мыши, чтобы их восстановить.
Исходный код, спрятанный в складке, не компилируется, поэтому спрятанные тесты ничего не "весят".
По моему, это удобно.
А что же Си/Си++?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>1) Известно, что Си-образный синтаксис использует больше лексем чем это реально необходимо. СГ>>2) Известно, что стандарты оформления Си-образного кода требуют использования большего количества строчек чем это реально необходимо (чтобы читающему понятно стало где что написано).
AVC>Сергей, Вы затронули интересную тему. AVC>В отличие от модераторов RSDN, я не считаю ее смешной.
Отличнно! Уже собирается анти-C-шная коалиция. А вы говорите, силы неравны.
Щя вам снова вспомнят и объем стандарта C++, и еще много чего.
Здравствуйте, moudrick, Вы писали:
M>Здравствуйте, AVC, Вы писали:
AVC>>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>>1) Известно, что Си-образный синтаксис использует больше лексем чем это реально необходимо. СГ>>>2) Известно, что стандарты оформления Си-образного кода требуют использования большего количества строчек чем это реально необходимо (чтобы читающему понятно стало где что написано).
AVC>>Сергей, Вы затронули интересную тему. AVC>>В отличие от модераторов RSDN, я не считаю ее смешной.
M>Отличнно! Уже собирается анти-C-шная коалиция. А вы говорите, силы неравны. M>Щя вам снова вспомнят и объем стандарта C++, и еще много чего.
M>:-D
Здравствуйте, CrystaX, Вы писали:
CX>А удобство это напрямую проистекает из количества нажатий клавиш. Вот если бы были клавиатуры, на которых каждая клавиша — это готовая лексема, тогда, возможно, что-то изменилось бы.
А это идея! Надо просто выпустить клавиатуры а-ля Спектрум, на которых будут нанесены все ключевые слова оберона — IF, THEN, END и т.д. И клавишу Enter спрятать подальше, чтобы поощрить написание кода в "однострочном" стиле.
Вот тогда то сишники и пообгрызут все локти от зависти
AVC>он абсолютно уверен, что перед следующим оператором после выхода из цикла выполняется условие ~p (NOT p). AVC>Если программист читает аналогичный цикл AVC>
AVC>while (p) { ... }
AVC>
AVC>на Си/Си++, он не может быть в этом уверен, т.к. внутри цикла может находиться как оператор break, так и знаменитый goto. AVC>Соответственно, проверка корректности программы существенно затрудняется.
а че в обероне нельзя из цикла выходить по брейку???
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Сергей Губанов, Вы писали:
AVC>а) Соответствие структурным принципам.
AVC>В отличие от синтаксиса Модулы/Оберона синтаксис Си/Си++ не соответствует принципам структурного программирования.
1. Ссылку на "принципы структурного программированитя" в студию.
AVC>Рассмотрим хотя бы циклы. AVC>Когда программист пишет (или, что важнее, читает) на Модуле/Обероне цикл AVC>
AVC>WHILE p DO ... END
AVC>
AVC>он абсолютно уверен, что перед следующим оператором после выхода из цикла выполняется условие ~p (NOT p). AVC>Если программист читает аналогичный цикл AVC>
AVC>while (p) { ... }
AVC>
AVC>на Си/Си++, он не может быть в этом уверен, т.к. внутри цикла может находиться как оператор break, так и знаменитый goto.
Ах, вот о чем речь? А что мешает Вам их не использовать?
А вот break действительно в C не совсем такой, какой (лично мне) хотелось бы. А мне хотелось бы такой как в Java — тогда точно goto не нужен ни в каком случае, даже из соображение эффективности.
Я вам могу сказать, какие приоритетные принципы у C++.
1. Поддержка максимального количества парадигм программирования (в том числе и структурного) здесь
2. Поддержка Legacy кода здесь
Поэтому, если считаете какое-то средство языка излишним — не используйте его.
AVC>Соответственно, проверка корректности программы существенно затрудняется.
AVC>б) Синтаксический "оверхед".
AVC>Я согласен с Сергеем, что в синтаксисе Си/Си++ заключен значительный "оверхед". AVC>Но таится он в основном в величине и сложности языка и его описания, а также в некоторых синтаксических деталях. AVC>Например, в количестве уровней и запутанности приоритетов операторов. AVC>Скажите честно: многие ли помнят таблицу приоритетов операторов Си/Си++ полностью? AVC>И сравните это с Обероном, где всего четыре уровня приоритетов: AVC>1) операция ~ (логическое отрицание); AVC>2) мультипликативные операции; AVC>3) аддитивные операции; AVC>4) сравнения. AVC>Остается добавить, что операции одного приоритета выполняются слева направо. И все. Что, сложно?
AVC>2. Исходные тексты Си/Си++ и документы Оберона.
AVC>Есть существенное различие в работе с исходными текстами программ на Си/Си++. AVC>Программа на Си/Си++ — это по-прежнему обыкновенный текст.
Самый переносимый формат данных.
AVC>Программа на Обероне — это документ, включающий в себя не только текст, но и множество самых разнообразных объектов.
Язык для описания этих объектов — в студию!
А потом поинкрементить описание оберона на язык описания объектов,
AVC>(Причем это различие существует еще с 1980-х годов.) AVC>ИМХО, это существенно сказывается на удобстве разработки. AVC>Попытаюсь это обосновать.
AVC>а) Документирование программ.
Самодокументирование + комментарии.
AVC>Вот простой пример. AVC>При разработке программы со сложным алгоритмом обыкновенно требуется делать ссылки на литературу: ищи пояснения в такой-то книге, на такой-то странице. AVC>Мне же оказалось достаточно взять требуемые фрагменты (и, что немаловажно, с "картинками" ) из документа, содержащего известную книгу Кормена, Лейзерсона и Ривеста, и вставить как комментарий в программу на Компонентном Паскале прямо перед соотвествующим им кодом.
Спецификацию методики вставки картинок в исходник на обероне — в студию!
AVC>Алгоритм теперь читается и понимается легко и даже приятно. AVC>Кроме того, благодаря тому, что все ключевые слова состоят только из заглавных букв и благодаря этому выделяются сами собой,
Вопрос — зачем их выделять, если они и так известны? Может как раз наоборот, их не надо делать выделяющимися?
программист может использовать цвет букв (а также размер и шрифт) по своему усмотрению для выделения особо важных фрагментов кода. Скажем, не уверен в данном коде — пометил его красным: проверить! Это очень эффективная система, т.к. цвет бросается в глаза, и такой участок кода трудно не заметить. AVC>Напоминаю, что подобные возможности доступны в Обероне с 1980-х. AVC>А что же Си/Си++?
А C/C++ разрабатывался как язык для работы с максимальным количеством девайсов. Цвет есть не у всех.
AVC>б) Тестирование программ.
AVC>Надеюсь, никто не будет спорить, что надо тестировать как программы в целом, так и отдельные компоненты и подпрограммы. AVC>На Си/Си++ тесты, как правило, хранятся в отдельных файлах и "запускаются" отдельными скриптами, которые тоже хранятся в отдельных файлах. В итоге, хранение этих вспомогательных, но необходимых файлов вырастает в целую проблему. AVC>(Я уж молчу о той деликатной детали, что многие Си++программисты вообще не хранят тестов. По принципу: протестировал — и забыл. Если не забыл протестировать... )
Это проблемы программиста, а не языка.
AVC>На Обероне/Компонентном Паскале тесты могут храниться в самом исходном документе: после точки или в комментарии. AVC>С помощью команд в обероновской среде можно запускать тесты для отдельных компонентов и даже отдельных подпрограмм. Для этого я помещаю тестовые команды прямо в исходном модуле, а коммандеры с исходными данными для тестов — после точки или в комментарии. Достаточно одного щелчка мыши, чтобы запустить нужный тест. AVC>После того, как я протестировал модуль, я не убираю тестовые команды в комментарии (и уж, тем более, не удаляю их!), а прячу в складку (fold). Опять же достаточно будет щелчка мыши, чтобы их восстановить. AVC>Исходный код, спрятанный в складке, не компилируется, поэтому спрятанные тесты ничего не "весят". AVC>По моему, это удобно. AVC>А что же Си/Си++?
Напиши тестовый енжин. Или возьми готовый, их немеряно.
По-моему, Вы опять путаете возможности среды и спецификации языка.
Либо же недоописываете стандарт Оберона.
Это все равно что путать "правила игры" и "технику игры". Знавал я таких (юных) преферансистов, среди которых бытовало прпвило "на третью даму не закладываться". Долго же я им объяснял, что понятие "третья дама" к правилам преферанса не имеет отношения, это элемент описания техники игры.
Здравствуйте, AVC, Вы писали:
AVC>Мне же оказалось достаточно взять требуемые фрагменты (и, что немаловажно, с "картинками" ) из документа, содержащего известную книгу Кормена, Лейзерсона и Ривеста, и вставить как комментарий в программу на Компонентном Паскале прямо перед соотвествующим им кодом. AVC>Алгоритм теперь читается и понимается легко и даже приятно. AVC>Кроме того, благодаря тому, что все ключевые слова состоят только из заглавных букв и благодаря этому выделяются сами собой, программист может использовать цвет букв (а также размер и шрифт) по своему усмотрению для выделения особо важных фрагментов кода. Скажем, не уверен в данном коде — пометил его красным: проверить! Это очень эффективная система, т.к. цвет бросается в глаза, и такой участок кода трудно не заметить. AVC>Напоминаю, что подобные возможности доступны в Обероне с 1980-х. AVC>А что же Си/Си++?
Так Вы о чем говорите? О языке или о IDE? Определитесь пожалуйста.
CX>...но вот ведь беда — пользователь мыслит не лексемами, а логическими блоками (узлами AST, если угодно). Так вот, что в первом, что во втором примере таких блоков одинаковое количество.
AVC>Вот простой пример. AVC>При разработке программы со сложным алгоритмом обыкновенно требуется делать ссылки на литературу: ищи пояснения в такой-то книге, на такой-то странице. AVC>Мне же оказалось достаточно взять требуемые фрагменты (и, что немаловажно, с "картинками" ) из документа, содержащего известную книгу Кормена, Лейзерсона и Ривеста, и вставить как комментарий в программу на Компонентном Паскале прямо перед соотвествующим им кодом. AVC>Алгоритм теперь читается и понимается легко и даже приятно. AVC>Кроме того, благодаря тому, что все ключевые слова состоят только из заглавных букв и благодаря этому выделяются сами собой, программист может использовать цвет букв (а также размер и шрифт) по своему усмотрению для выделения особо важных фрагментов кода. Скажем, не уверен в данном коде — пометил его красным: проверить! Это очень эффективная система, т.к. цвет бросается в глаза, и такой участок кода трудно не заметить. AVC>Напоминаю, что подобные возможности доступны в Обероне с 1980-х. AVC>А что же Си/Си++?
По-моему, вы путаете понятие среды и языка. Что, если я напишу IDE, обрабатывающую Обероны безо всех этих фич? Или тот же Zonnon, если его прикрепят к Visual Studio, автоматом позволит мне все это делать?
Эх, ностальгия..... Напомню, что все эти псевдо-фичи среды Блэкбокс уже обсуждались. Например, здесь показано
, что вставка объектов в текст ни в коем случае не делает его читаемым. потому что извините, но картинка, документация, форма и код — это диаметрально противоположные понятия.
Не спорю, их можно сделать, но подумав головой, например, как это делают в Visual Studio 2010 Concept IDE. Чувствуете разницу?
Здравствуйте, CrystaX, Вы писали:
CX> Для кого это правильно?
Вообще. Без относительно к чему-либо. Теорема Пифагора для кого правильна?
CX>В первом случае мне понадобилось 10 нажатий клавиш. Во втором — 15.
+ CX>пользователь мыслит не лексемами, а логическими блоками
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, CrystaX, Вы писали:
CX>> Для кого это правильно?
СГ>Вообще. Без относительно к чему-либо. Теорема Пифагора для кого правильна?
Для Евклидового пространства.
В протифном случае вступает в силу Дефект Треугольника.
Анадлогия не принята, вопрос повторяется — Для кого это правильно?
Более научно — в случае выполнения каких ограничений?
CX>>В первом случае мне понадобилось 10 нажатий клавиш. Во втором — 15. СГ> + CX>>пользователь мыслит не лексемами, а логическими блоками
СГ>Поэтому сами буквы не считаются.
Поэтому же не считаются и скобки.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, CrystaX, Вы писали:
CX>> Для кого это правильно?
СГ>Вообще. Без относительно к чему-либо. Теорема Пифагора для кого правильна?
Безотносительно не бывает. Та же теорема Пифагора действует только в Евклидовой геометрии. А в геометрии Лобачевского? Не бывает абсолютной истины.
Поэтому я настаиваю на том, что правильность синтаксиса — понятие относительное, и для большинства программистов (пользователей того или иного языка) более удобным является C-like синтаксис. Это, кстати, ответ на Ваш вопрос о том, доколе этот синтаксис будет жив.
CX>>В первом случае мне понадобилось 10 нажатий клавиш. Во втором — 15. СГ> + CX>>пользователь мыслит не лексемами, а логическими блоками
СГ>Поэтому сами буквы не считаются.
Ну почему же не считаются? Ведь в лексемы они не силой мысли превращаются, а с помощью вполне осязаемых и исчислимых нажатий на клавиатуре. Аргумент не принимается. Если бы были клавиатуры с лексемами — тогда аргумент я бы принял.
Здравствуйте, AVC, Вы писали:
AVC>В отличие от синтаксиса Модулы/Оберона синтаксис Си/Си++ не соответствует принципам структурного программирования.
AVC>
AVC>while (p) { ... }
AVC>
AVC>на Си/Си++, он не может быть в этом уверен, т.к. внутри цикла может находиться как оператор break, так и знаменитый goto. AVC>Соответственно, проверка корректности программы существенно затрудняется.
Совершенно согласен. Сам на позапрошлой неделе в своей программе на C# обнаружил, что переменная цикла while после его завершения иногда становилась равной -1 вместо ожидаемого минимального значения 0. Ошибка конечно чрезвычайно глупая и мне за нее стыдно, но дело в том, что на Обероне я бы ее просто НЕ СМОГ бы совершить в принципе!
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, AVC, Вы писали:
AVC>>В отличие от синтаксиса Модулы/Оберона синтаксис Си/Си++ не соответствует принципам структурного программирования.
AVC>>
AVC>>while (p) { ... }
AVC>>
AVC>>на Си/Си++, он не может быть в этом уверен, т.к. внутри цикла может находиться как оператор break, так и знаменитый goto. AVC>>Соответственно, проверка корректности программы существенно затрудняется.
СГ>Совершенно согласен. Сам на позапрошлой неделе в своей программе на C# обнаружил, что переменная цикла while после его завершения иногда становилась равной -1 вместо ожидаемого минимального значения 0. Ошибка конечно чрезвычайно глупая и мне за нее стыдно, но дело в том, что на Обероне я бы ее просто НЕ СМОГ бы совершить в принципе!
Перекуём баги на фичи!
Вон, я ошибку в простейшем слове допустил 
Надо просто выпустить клавиатуры а-ля Спектрум, на которых будут нанесены все ключевые слова оберона — IF, THEN, END и т.д. И клавишу Enter спрятать подальше, чтобы поощрить написание кода в "однострочном" стиле.
