Здравствуйте, Сергей Губанов, Вы писали:
СГ>Ни в каком учебном заведении я ее не защищал. Я ее защищал в одном из самых престижных институтов РАН по теоретической физике. Но к программированию она отношения не имеет. Тема диссертации "Квантовая групповая редукция XXZ модели Гейзенберга".
"Есть такие люди, которым стоит только подойти к прибору, как он сразу же ломается. Такие люди называются физиками-теоретиками." (с) Физики шутят
Здравствуйте, algol, Вы писали:
A>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Ни в каком учебном заведении я ее не защищал. Я ее защищал в одном из самых престижных институтов РАН по теоретической физике. Но к программированию она отношения не имеет. Тема диссертации "Квантовая групповая редукция XXZ модели Гейзенберга".
A>"Есть такие люди, которым стоит только подойти к прибору, как он сразу же ломается. Такие люди называются физиками-теоретиками." (с) Физики шутят
Не, не шутят. Шутка — это лишь форма отражения действительности. То есть в шутках физиков изложены факты, которые сами физики, как ни стараются, объяснить не могут.
Здравствуйте, Пацак, Вы писали:
П>Символы (не считая отступов): 113;
Пробелы в Обероне являются синтаксически важными элементами. Они разделяют лексемы.
(пробел — это последовательность пробельных символов, переводов каретки и комментариев).
Оберон с его голыми ключевыми словами требует вставку разделителей — будь то нейтральные лексемы (скобки и ";") или пробелы.
IFcTHENtELSEeEND (* неправильно *)IF c THEN t ELSE e END(* с пробелами *)IF(c)THEN t;ELSE e;END(* с нейтральными лексемами *)IF(**)c(**)THEN(**)t(**)ELSE(**)e(**)END(* с пробелами из комментариев *)
В С++ потребность в пробельных разделителях меньше: гораздо чаще синтаксис явно требует разделительные лексемы.
if(c)t;elsee; // неправильно
// v-v-v------v--- обязательные лексемы-разделителиif(c)t;else e;
// ^----- вот здесь пробел потребовался
Здравствуйте, Кодт, Вы писали:
К>Теоретически, нет разницы между теорией и практикой. Практически же, разница есть.
К>Реалтайм можно дебажить — начиная от хардверных стендов и кончая самыми разными чисто софтверными инструментами (журнал обращений к ОС, отладочный вывод, а то и пошаговое выполнение отдельных задач). К>Пример: умело расставляя приоритеты нескольким задачам, ввели систему в жуткие тормоза. Журнал показал, что идёт битва за один системный мутекс (в менеджере памяти), а расстановка меток выявила участки кода, где захват этого мутекса приводил к дребезгу. К>Дальше было тонкое колдовство над временной диаграммой...
У каждой системы свои нюансы. Часто приходилось отлаживать программу на контроллере, у которого из индикаторов только пара светодиодов...
Здравствуйте, Socrat, Вы писали:
S>У каждой системы свои нюансы. Часто приходилось отлаживать программу на контроллере, у которого из индикаторов только пара светодиодов...
In-cirquit programmer, а тем более in-cirquit debugger — очень полезный паттерн проектирования схемотехники...
Иначе забодаешься выковыривать чип из кроватки (а тем более — не дай бог — выпаивать).
Сергей Губанов wrote:
> 1) Вот смотрите, заменим все служебные слова на символ "*" > >REPEAT x UNTIL b = * x * b >WHILE a DO x END = * a * x * >IF a THEN x END = * a * x * >IF a THEN x ELSE y END = * a * x * y * >IF a THEN x ELSIF b THEN y ELSE z END = * a * x * b * y * z * >CASE n OF a: x | b: y ELSE z END = * n * a * x * b * y * z * > >
> между каждым "пользовательским" идентификатором стоит не более одной > звездочки. Меньше одной звездочки поставить нельзя (если конечно не > перегружать пробельные символы дополнительным смыслом кроме того что у > них и так уже натурально есть). Значит минимум достигнут. Больше одной > звездочки — это уже оверхед. Если расписать аналогичные Си-образные > конструкции, то там будет куча лишних звездочек.
Агащаз:
x until b
x * b - было в одном из Perlовых DSLей.
while a : x
* a * x
Python.
a->x ; b (аналог IF ..THEN..ELSE..END)
a * x * b
и т.п.
А есть еще функциональные языки, конструкции которых вообще в Обероне
нормально выразить нельзя.
> 3) По поводу оберонов даже говорят: /Изобрести еще один "Оберон" так > же невозможно, как невозможно изобрести еще один автомат Калашникова/.
M>> Дебагить его тоже невозможно
СГ>Похоже для всех Си-образных программистов сидение в дебагере — это основное времяпрепровождение. СГ>А Вы вообще в курсе, что есть класс программ, которые в принципе нельзя дебажить? СГ>(например, системы реального времени нельзя дебажить по определению)
Мы же не о таких системах говорим н данный момент.
СГ>Лично я, например, в дебагере не сижу вообще: СГ>1) Использую математически доказуемые алгоритмы. СГ>2) Если не могу выполнить пункт (1), то делаю так что программа сама сообщает где ошибка.
И это вы так делаете, начиная с первого же дня работы с незнакомым вам языком/системой/модулем? Предположим, к проекту подлючен модуль стороннего программиста, который в одно из десяти случаев ведет себя не так, как надо. Автор модуля уехал на Багамы.
Придется разбирать код и дебажить. Увы. Причем конструкции типа
WHILE (p.next # NIL) & (p.next.key < key) DO p := p.next END;
не способствуют ни тому, ни другому.
M>> На более-менее реальных примерах Оберон в десятки раз проигрывает в читаемости.
СГ>А вот тут как на счет читаемости: СГ>
Не спорю, здесь код тоже неудобоваримый, но! Есть одно немаловажное но, которое относится к простому коду. Так вот. В простом коде С-подобные языки выигрывают по сравнению с Обероном за счет меньшего количества визуального мусора. Ну нельзя просто психологически заставлять половину текста писать заглавными буквами. В итоге код кричит, а глаз цепляется за не несущую функциональную нагрузку слова.
Так вот. Опять же. Вы цепляетесь за какие-то мелочи, приводите высосанные из пальца примеры, несмотря на то, что уже не впервый раз:
, в которых доказывалось отсутствие в Обероне конструкции BEGIN..END, несмотря на то, что она существует для ключевых блоков MODULE, PROCEDURE, FUNCTION и выродилась в ..END для всех остальных блочных конструкций.
б) С вашей стороны не было приведено ни одного приближенного к реальному кода. Ладно, пришлось нахдить код самому. И что? Опять ни одного контраргумента, кроме опят таки высосанного из пальа примера на С, который якобы доказывает несостоятельность всего синтаксиса языка в целом. Гррр (рычит, рвет на себе волосы и мчет молнии )
Ладно. Начнем сначала ...
Вот пример хорошего, добоваримого кода на С++ (взято из исходников Qt):
bool QBitArray::fill( bool v, int size )
{
if ( size >= 0 ) {
if ( !resize( size ) )
return FALSE;
} else {
size = this->size();
}
if ( size > 0 )
memset( data(), v ? 0xff : 0, (size + 7) / 8 );
if ( v )
pad0();
return TRUE;
}
Тот же код на Оберонах, насколько я понимаю, будет выглядеть примерно так:
FUNCTION QBitArray.fill(v : BOOLEAN, size : INTEGER) : BOOLEAN
VAR
tmp : INTEGER;
BEGIN
IF size >= 0 THEN
IF resize( size ) # FALSE THEN
fill := FALSE;
ELSE
size := self.size;
END
IF size > 0 THEN
IF v = TRUE THEN tmp := 0xFF ELSE tmp := 0; END;
memset( data, tmp, (size + 7) / 8 );
END;
IF v = TRUE THEN pad0; END;
fill := TRUE;
END fill;
Померяемся пиписьками?
На 14 строк С++ кода — 49 "левых" символов (запятые, скобки, точки с запятой, знаки больше/меньше)
На 17 строк Оберон-кода — не буду считать весь визуальный мусор в виде слов BEGIN, END, THEN — но его явно больше.
Главное в языке — не лексемы, а то, насколько его удобно читать.
ЗЫ. Только не надо перечислять, какие ошибки я допустил в Обероновском коде.
... << RSDN@Home 1.1.4 beta 7 rev. 447>> ... <<Winamp is playing "Silence">> ...
Здравствуйте, Mamut, Вы писали:
M>б) С вашей стороны не было приведено ни одного приближенного к реальному кода. Ладно, пришлось нахдить код самому. И что? Опять ни одного контраргумента, кроме опят таки высосанного из пальа примера на С, который якобы доказывает несостоятельность всего синтаксиса языка в целом.
На самом деле тот пример писал я, и сделать его удобочитаемым — цели не стояло. Сергей кидался в одну крайность — использование простейших конструкций с односложными вызовами процедур, я кинулся в другую и втиснул максимум действий в строку текста, показав, что лаконизм инструкций в C/C++ достигается иными методами, нежели в Обероне.
M>>б) С вашей стороны не было приведено ни одного приближенного к реальному кода. Ладно, пришлось нахдить код самому. И что? Опять ни одного контраргумента, кроме опят таки высосанного из пальа примера на С, который якобы доказывает несостоятельность всего синтаксиса языка в целом.
П>На самом деле тот пример писал я, и сделать его удобочитаемым — цели не стояло. Сергей кидался в одну крайность — использование простейших конструкций с односложными вызовами процедур, я кинулся в другую и втиснул максимум действий в строку текста, показав, что лаконизм инструкций в C/C++ достигается иными методами, нежели в Обероне.
Это я виноват Я знаю, что это был твой пример, просто лень было мысль ясно выражать. Я имел в виду, что происходят неудачные мнипляции общественным сознанием , когда для доказательств используются крайние случаи и нереальные примеры, пусть даже и не свои. Вот.
Кстати, вполне очень даже понятно, что в том примере написано Правда, не представляю, зачем такая конструкция могла бы понадобится..
... << RSDN@Home 1.1.4 beta 7 rev. 447>> ... <<Winamp is playing "Silence">> ...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, viellsky, Вы писали:
V>> небольшие проценты.
СГ>Вопрос СГ>Сколько процентов можно считать небольшим числом?
СГ>Правильный ответ СГ>Только ноль.
месье, я вам обязательно отвечу, но для начала мне нужно знать, чем отличаются "разы" от "процентов" в вашей фразе: СГ>Программа записанная в Си-образном синтаксисе содержит в разы, а не на проценты больше лексем и строчек кода чем это реально необходимо. Спрашивается, и как долго этот синтаксис еще будет существовать? я просто пытался подстроиться под вашу терминологию...
Также и пишется: str1 := str2, равно как для любых массивов arr1 := arr2 (соответствующих типов — ведь массивы это самый обычный value-type, а значит можно так присваивать — нет исключений из правил).
Для ARRAY OF CHAR есть еще специальное копирование имеющее строковую семантику, а не массивовую — до первого 0X символа включительно. Пишется так str1 := str2$
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Также и пишется: str1 := str2, равно как для любых массивов arr1 := arr2 (соответствующих типов — ведь массивы это самый обычный value-type, а значит можно так присваивать — нет исключений из правил).
В данном конкретном случае — да. Вот только кто сказал, что str1 и str2 — это обязательно должны быть строки или массивы? Вполне возможно, что это экземпляры каких-то хитрых классов, операции над которыми (копирование, сложение, адресация к элементу и т.п.) должны сопровождаться некими дополнительными действиями (скажем, изменением состояния некоего третьего объекта). Что тогда? В C++ я переопределю оператор, в питоне — перекрою метод класса, а в Обероне?