Здравствуйте, fddima, Вы писали:
F>Обероне/Паскале абсолютно ненужные лексемы: F>procedure F>function F>var F>do F>to, downto F>...
Если не обращать внимания на регистр, то лишние здесь function и downto.
Для процедур-функций используется то же самое служебное слово, что и для процедур — PROCEDURE.
Слова downto, нет вообще. Дело в том, что в оригинальном обероне нет цикла FOR. Во втором обероне цикл FOR есть, но в нем есть слово BY после которого надо написать шаг (положительный или отрицательный, так что downto не нужен).
FOR i := 0 TO -100 BY -5 DO ... END
BY — не обязательное слово. Если его нет, то по умолчанию полагается шаг = +1.
F> Я в искренном недоумении.
Теперь что касается искреннего недоумения... Переисленные лексемы не являются абсолютно не нужными, а наоборот, причем это очевидно для любого кто знает этот язык и понимает почему он именно такой, а не другой. Отсюда, собственно, и происходит мой шуточный ответ.
Здравствуйте, Курилка, Вы писали:
К> Сергей, а вы не пробовали подсчитать оверхэд больших букв над маленькими?
Лексикой я не занимался, только синтаксисом.
С точки зрения синтаксиса любая лексема рассматривается как один знак, не зависимо от того из скольки и каких именно букв она реально состоит.
Лексический оверхед подсчитывать особого смысла нет, ведь всегда можно создать такой текстовый редактор, в котором лексемы представлялись бы в виде одного иероглифа. Например, в системе Mathematica лексемы "не равно" (#8800), "принадлежит" (#8712), "больше или равно" (#8805), "сумма" (#8721) и т.д. отображаются соответствующими значками как это принято в математической литературе.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Если не обращать внимания на регистр, то лишние здесь function и downto. СГ>Для процедур-функций используется то же самое служебное слово, что и для процедур — PROCEDURE.
Т.е. вывод => procedure всё таки нужное служебное слово.
СГ>Слова downto, нет вообще. Дело в том, что в оригинальном обероне нет цикла FOR. Во втором обероне цикл FOR есть, но в нем есть слово BY после которого надо написать шаг (положительный или отрицательный, так что downto не нужен). СГ>FOR i := 0 TO -100 BY -5 DO ... END СГ>BY — не обязательное слово. Если его нет, то по умолчанию полагается шаг = +1.
Принципиально не обязательное. А по факту оно есть.
F>> Я в искренном недоумении. СГ> Теперь что касается искреннего недоумения... Переисленные лексемы не являются абсолютно не нужными, а наоборот, причем это очевидно для любого кто знает этот язык и понимает почему он именно такой, а не другой. Отсюда, собственно, и происходит мой шуточный ответ.
Ну, мы уже давно не в "Коллеги, улыбнитесь". Притом даже смайликов нет.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>1) Известно, что Си-образный синтаксис использует больше лексем чем это реально необходимо. СГ>2) Известно, что стандарты оформления Си-образного кода требуют использования большего количества строчек чем это реально необходимо (чтобы читающему понятно стало где что написано).
Кстати, обртите внимание на цепочку операторов разыменования указателей в Паскале
В C в этом случае пришлось вводить новый оператор абсолютно на пустом месте, просто из-за непродуманного синтаксиса
Здравствуйте, SilverCloud, Вы писали:
SC>Кстати, обртите внимание на цепочку операторов разыменования указателей в Паскале SC>В C в этом случае пришлось вводить новый оператор абсолютно на пустом месте, просто из-за непродуманного синтаксиса
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, SilverCloud, Вы писали:
SC>>Кстати, обртите внимание на цепочку операторов разыменования указателей в Паскале SC>>В C в этом случае пришлось вводить новый оператор абсолютно на пустом месте, просто из-за непродуманного синтаксиса
П>А что, в C нет оператора разыменования указателя?
Блин, ты, похоже, не вкурил, о чём речь. В том-то и дело, что оператор "звёздочка" в C есть, и оператор "точка" тоже есть, но опльзоваться ими в такой ситуации, как в приведённом коде — фиаско (напиши, и сам увидишь). Поэтому введён оператор "стрелка", который, в общем-то нужен только для обхода этого ужасного синтаксиса. Паскаль без этого костыля прекрасно обходится.
Здравствуйте, SilverCloud, Вы писали:
SC>Блин, ты, похоже, не вкурил, о чём речь. В том-то и дело, что оператор "звёздочка" в C есть, и оператор "точка" тоже есть, но опльзоваться ими в такой ситуации, как в приведённом коде — 3.14здец (напиши, и сам увидишь). Поэтому введён оператор "стрелка", который, в общем-то нужен только для обхода этого ужасного синтаксиса. Паскаль без этого костыля прекрасно обходится.
А, ну это да, согласен. Хотя меня лично стрелка никогда не напрягала.
SC>Кстати, обртите внимание на цепочку операторов разыменования указателей в Паскале SC>В C в этом случае пришлось вводить новый оператор абсолютно на пустом месте, просто из-за непродуманного синтаксиса
Кстати, в оберонах символ разыменования "^" в очевидных (однозначных) случаях писать не обязательно:
СГ>аналогично обстоит дело и в Дельфи. Компилятор понимает что имеется в виду.
А потом сидишь в чужом коде разбираешься, и не может понять, как оно работает, пока не посмотришь на объявление переменной.
СГ>>аналогично обстоит дело и в Дельфи. Компилятор понимает что имеется в виду. MF>А потом сидишь в чужом коде разбираешься, и не может понять, как оно работает, пока не посмотришь на объявление переменной.
То есть Вы за то чтобы всегда писать "^." вместо "." даже если это очевидно? Суровый Вы человек, однако...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>То есть Вы за то чтобы всегда писать "^." вместо "." даже если это очевидно?
Стараюсь только так и писать. СГ>Суровый Вы человек, однако...
Когда появляются неоднозначность, с вероятностью в 90% появится и ошибка.
В продолжение сабжа: мне действительно без разницы, какой оверхед у Си или паскаля,
я хочу, чтоб код нормально читался и понимался.
Спорить какой синтаксис лучше (си/паскаль/оберон) не хочу, некоторые вещи мне нравятся в Сях некоторые в делфе, и соответственно наоборот много не нравится и там и там. Идеального не бывает.
M>Тогда зачем там слово procedure? Оверхед
У вас void (либо тип возвращаемой переменной) — что с того? PROCEDURE означает начало описания процедуры, некоторой программной единицы. Также как TYPE — описание типа, CONST — описание констант и т.д. Целостно? На мой взгляд да. Лучше, чем С++? Хуже? Не знаю, вопрос привычки.
M>Итак. Посчитаем (а мы ведь любим считать). В рамках данного исследования я визуальным шумом называю служебные слова M>и выражения, служебные символы и лексемы. Кодом я называю то, что юзера интересует — переменные, имена функций, M>цифры. Итак:
M>Перед тестом есь текст был выровнян по левому краю и убраны пробелы в конце строчек. Статистика — по MS Word M>Оберон M>Всего тескта: 270 символов (330 — с пробелами) M>Код: 94 символа
M>Код/Текст: ~0.35
M>C++ M>Всего текста: 170 символов (214 — с пробелами) M>Код: 65 символов
M>Код/Текст: ~0.38
M>Оп-па. Сюрприз-сюрприз! С точки зрения того, что и где писать — пофиг, что Оберон, что С++. Но обратите внимание, M>_сколько_ надо писать в Обероне.
Служебные слова — это не шум, это должно быть отделено от творчества программиста тем или иным образом. Для этого вы и подсвечиваете код разными цветами. В Оберонах это делается капитализацией, а подсвечивание делается, например, для выделения спорных фрагментов кода, нововведений (ещё не оттестированных) и т.д.
Считать любите? Человек читает не по буквам, а словами (как минимум) и читать привык слова, а не символы ({} && $$ :: и т.д.). Впрочем, опять же, кто к чему привык.
M>А теперь.... Маэстро, туш. M>Предлагаю всем присутствующим принять участие вот в этом эксперименте, в котором определяется насколько легко находить определенный текств другом — в зависимости от выравнивания текста и того, написан текст заглавными или строчными буквами. Если хотите, можете посмотреть результаты, котрые говорят, что если текст написан заглавными буквами, то его сложнее читать.
M>Все еще не убеждены? Возьмем куски кода сверху и пропустим их через анализатор: M>
M>С++
M>Flesch-Kincaid Reading Ease: 62
M>Ideally, web page text should be around the 60 to 80 mark on this scale. The higher the score, the more readable the text.
M>Flesch-Kincaid Grade Level: 10
M>Ideally, web page text should be around the 6 to 7 mark on this scale. The lower the score, the more readable the text.
M>Gunning-Fox Index: 17
M>Ideally, web page text should be between 11 and 15 on this scale. The lower the score, the more readable the text. (Anything over 22 should be considered the equivalent of post-graduate level text).
M>Оберон
M>Flesch-Kincaid Reading Ease: -709
M>Ideally, web page text should be around the 60 to 80 mark on this scale. The higher the score, the more readable the text.
M>Flesch-Kincaid Grade Level: 315
M>Ideally, web page text should be around the 6 to 7 mark on this scale. The lower the score, the more readable the text.
M>Gunning-Fox Index: 332
M>Ideally, web page text should be between 11 and 15 on this scale. The lower the score, the more readable the text. (Anything over 22 should be considered the equivalent of post-graduate level text).
M>Как говорят англичане — ouch, it hurts.
А вот это вообще ни в какие ворота! Взять тестя читабельности ОБЫЧНЫХ текстов, которые оценивают читабельность исходя из длины и конструкции предложений и впендюрить в них исходные коды! Мухлёж, елы-палы. Хорошо вам, что народ ленивый попался, посмотрел на цифирьки и кивает согласно, молодец, чувак, уел оберонцев. В сад такие тесты.
M>В университетах учат, что для повышения читаемости текста необходимо избегать заглавных букв.
Про заглавные буквы было выше, скажу лишь, что если бы ВЕСЬ исходный текст писался заглавными буквами, то придирка была бы засчитана. А так — нет. Зачем, по вашему, предложения начинаются с заглавных букв? Уж наверное для затруднения чтения. Явно.
M>Я все больше и больше убеждаюсь в непригодности Оберона к написанию сколько-нибудь длинного кода из-за его вопиющей нечитаемости.
Это вам кажется, точнее — это ВАМ кажется. Многим удобнее читать код Оберона.
M>Тепреь опять оп! Сейчас мне возразат, что если бы се было так плохо, то Оберон не стали бы использовать на атомных станциях Знаете, и на ассемблере можно написать очень серьезные системы (и писали!). Но является ли это знаком того, что это великолепный язык с безупречным синтаксисом? Никак нет.
Мимо кассы.
M>Современные _мэйнстрим_ языки программирования находятся где-то посредине между ассемблерным и паскальным синтаксисом, потому что такой синтаксис позволяет наиболее эффективно выразить все необходимые конструкции языка и позволяет в них, конструкциях и языках, довольно легко разобраться.
Мимо кассы.
M>На данный момент существуют десятки языков, которые позволяют выражать мысли намного эффективнее, чем Оберон (возьмем Perl и манипуляцию стрингами, например). Существуют десятки языков, которые позволяют выражать мысли намного понятнее, чем Оберон (русский, например или С++ — да, С++!). Оберон не хуже и, главное, не лучше этих языков. Он всего лишь один из таких языков со своим, весьма грубым синтаксисом и непонятным будущим. Но делать из него культ? Подсчитывать лексемы? Извините, у многих есть дела поважнее
Мимо кассы. Если в голову намертво вбит С++, то всё остальное кажется туфтой малопригодной. Пускай, только не надо при этом казаться объективным и сыпать какой-то статистикой, изгаляться как-то ещё. Просто заявите:"Да, я люблю С++, да он мне кажется венцом, да мне близок его синтаксис, да-да-да, но это моё личное мнение, прошу принять это во внимание".
С уважением, человек, пишущий на FORTRAN.
Здравствуйте, Chervyachok, Вы писали:
M>>Тогда зачем там слово procedure? Оверхед C>У вас void (либо тип возвращаемой переменной) — что с того?
Ты топик (довольно старый кстати, нафига вообще было его поднимать? ) весь прочитал или просто ткнул "ответить" на случайном письме? Начинался он с того, что C++ обвинили в обилии "лишних" синтаксических элементов, не нужных, дескать, компилятору. Когда разумные аргументы о том, что на трудности компилятора программеру начхать, и куда важнее читабельность программы, не возымели действия — над оберонистами начали банально стебаться, указывая на бревна в их собственном глазу. Отквоченое тобой — один из таких примеров, не надо воспринимать его серьезно, никто не заставляет оберонистов выкидывать все "лишнее" из своего языка — пусть только не трогают чужие.
C>Служебные слова — это не шум, это должно быть отделено от творчества программиста тем или иным образом.
Нафига? Программист мыслит не "словами", а "предложениями" — строками и блоками кода. И далеко не всегда управляющие структуры языка играют в них основную роль — зачастую используемые модули и классы позволяют сделать что-то, полностью скрывая при этом реализацию. Скажем эти два фрагмента чисто технически могут делать одно и то же, при том, что во втором нет вообще ни одного служебного слова. И что в нем выделять?
1.
VAR
len : INTEGER;
i : INTEGER;
item : SomeClass;
BEGIN
len = collection.length;
FOR i := 1 TO len DO
item := collection.get(i);
IF item.isAccessible() THEN
process(collection.get(i));
END
END
END
Куда важнее ИМХО возможность выделения не "слов", а именно "предложений" — корректно расставленные отступы, например, или единый для команды coding-style. Но это-то как раз лежит за пределами использования цветовой подсветки и/или заглавных букв.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Программа записанная в Си-образном синтаксисе содержит в разы, а не на проценты больше лексем и строчек кода чем это реально необходимо. Спрашивается, и как долго этот синтаксис еще будет существовать?
Я надеюсь, что еще очнеь долго
Сишный синтаксис — это лучшее что сейчас есть. Недаром многие распространенные языки — C++, ObjC, Java, C#, JavaScript, PHP, Perl — основаны именно на сишном синтаксисе.
А синтаксис Паскаль-Ада слишком громоздкий. Это же додуматься надо: вместо {} писать begin end! синтаксический оверхед уже здесь 400% (8 символов вместо двух, а если учесть что перед и после begin/end нужно ставить пробелы, то и вовсе 600% )
далее: скобки для аргументов операторов — просто замечательная идея! например, сравним
if(x) f(x)
if x then f(x) end
подсчитайте символы — оверхед 200%
но даже это не главное: скобки выделяют аргумент логически. Воспринимать такой код гораздо проще.
Есть конечно некоторые мелкие недостатки, но они вполне устранимы, и, возможно, когда-нибудь в очередном си-подобном языке их и устранят (кстати, в Scala и Nemerle уже многое устранили)
В частности, можно улучшить определение функций: вместо
int func(int x, int y)
использовать
def func(int x, y):int
это существенно облегчит парсинг и динамическую поддержку различных Class Viewer'ов, особенно если в языке есть вложенные функции, и создаст единообразие в определении объектов всех видов (ключевое слово — имя — декларативное описание)
Еще в С++ следовало бы упростить синтаксис шаблонов, убрать template и использовать обычные скобки
class Array(typename T, int size)
{
};
Array(char,100) m_list;
в продвинутых языках кстати так и делают.
А в остальном сишный синтаксис вполне даже идеален
ЗЫ: наверняка все это уже отвечали, читать тему не стал, ибо это нереально
Здравствуйте, x-code, Вы писали:
СГ>>Программа записанная в Си-образном синтаксисе содержит в разы, а не на проценты больше лексем и строчек кода чем это реально необходимо. Спрашивается, и как долго этот синтаксис еще будет существовать?
XC>Я надеюсь, что еще очнеь долго
Нет, эта мегаветка будет жить вечно!
XC>ЗЫ: наверняка все это уже отвечали, читать тему не стал, ибо это нереально
Ты знал!!!
По-моему, это лучшая отмазка для некропостинга!
Кодт wrote: > XC>ЗЫ: наверняка все это уже отвечали, читать тему не стал, ибо это > нереально > Ты знал!!! > По-моему, это лучшая отмазка для некропостинга!
О Боже! Я же в эту ветку еще и писал!
Может сделать специальный форум для таких веток: "Музей RSDN"
Здравствуйте, Cyberax, Вы писали:
C>Кодт wrote: >> XC>ЗЫ: наверняка все это уже отвечали, читать тему не стал, ибо это >> нереально >> Ты знал!!! >> По-моему, это лучшая отмазка для некропостинга! C>О Боже! Я же в эту ветку еще и писал!
ну не я ее поднял а ответил в общем от нечего делать
Здравствуйте, Cyberax, Вы писали:
C>Кодт wrote: >> XC>ЗЫ: наверняка все это уже отвечали, читать тему не стал, ибо это >> нереально >> Ты знал!!! >> По-моему, это лучшая отмазка для некропостинга! C>О Боже! Я же в эту ветку еще и писал!
C>Может сделать специальный форум для таких веток: "Музей RSDN"
Лучше "Почётные дятлы RSDN"...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Тот, кто желает, но не делает, распространяет чуму.
Перекуём баги на фичи!
а ответил в общем от нечего делать
