Ответ на »сообщение 1695« (Снегурочка)
___________________________
И отказаться от него только потому, что в обероне его нет (по весьма специфичным для создателя оберона причинам) и лично товарищ info21 считает оберон экстремумом функции простоты/надежности/выразительности (опираясь в своих доказательствах только на красоту слога), я не могу.
А кто лично Вас заставляет жертвовать? Выбирайте себе другой язык для своих задач, где наличие перечисления столь важно. В чем проблема? Или кто-то принуждает Вас использовать именно Оберон или КП?
Не кто, а - что. Это самое простое проявление неких комплексов. (Самое простой пример можно у Шукшина в одном из его рассказов встретить: http://lib.ru/SHUKSHIN/srezal.txt ) Людям нужно оправдание и обоснование своего поступка и положение в этом мире, вв том деле, которым они занимаются. Против математики и сухих выкладок с не менее сухими (а, для многих ещё и удручающими и непонятными) выводами, "перевесить" может только клоунада, улюлюканье и напор. В глубине души все прекрассно осознают, на чьей стороне ИСТИНА, но вот подишь-ты,- ну просто не быть могут миллионы "пареньков от сохи" не правыми по стравнению с сотней-другой "яйцеголовых"! :о))) Тем более, что первых именно к такой "удобности" и "жизнеприспособленности" приучили...

Ответ на »сообщение 1694« (pepper)
___________________________

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

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

Ответ на »сообщение 1692« (AVC)
___________________________


Оберон не предлагает сменить "компьютер на счеты".
Скорее, он предлагает сменить "CISC на RISC".


А зачем? Судьба PowerPC прельщает?


Вообще, никто здесь не предлагал пожертвовать вычислительными возможностями "ради простоты".
Здесь, собственно, Вы и подменили понятия (думается, неумышленно).


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

>>>Выкинь свой компьютер и купи счеты.
Коллега, не надо обижать счеты!
Счеты, между прочим, есть блестящий пример устройства, в котором сложность реализации точно соответствует сложности его функционального назначения. Вот если бы мы начали прикручивать к счетам еще какие-то рычажки, колесики и винтики, да еще написали бы инструкцию по эксплуатации в 800 страниц - тогда мы бы пошли по пути "технического ожирения". И тогда пришлось бы организовывать курсы по обучению работе со счетами, сервисные службы по их обслуживанию. Не реже, чем раз в полгода, выпускались бы "сервис-паки" для исправления гнутых колесиков и других погрешностей в конструкции.
Если бы каждый программный продукт был спроектирован так же просто и гениально, как счеты, то насколько проще и надежнее стало бы программное обеспечение.

Ответ на »сообщение 1690« (pepper)
___________________________

Ответ на »сообщение 1688« (AVC)
___________________________


>>Эффектная фраза, конечно. :)
Но стоит ли ради красного словца подменять понятия?
Ведь речь идет вовсе не о любой сложности, а об избыточной.


А критерием избыточной сложности является оберон. Это аксиома? Это понятие я "подменил"? Если не аксиома, то это требует каких-то доказательств, помимо рассуждений о принципе Калашникова.

Оберон не предлагает сменить "компьютер на счеты".
Скорее, он предлагает сменить "CISC на RISC".

Вообще, никто здесь не предлагал пожертвовать вычислительными возможностями "ради простоты".
Здесь, собственно, Вы и подменили понятия (думается, неумышленно).

Ответ на »сообщение 1689« (AVC)
___________________________

Как вы считаете, практичны ли однопроходные компиляторы в нынешних обстоятельствах?
Для меня это серьезный вопрос.

Ну ты же сам знаешь ответ в oberon-way - непрактичны, потому что сложнее однопроходных. Это все та же "проблема перечислимого типа", только с другого боку :)

Ответ на »сообщение 1688« (AVC)
___________________________


Эффектная фраза, конечно. :)
Но стоит ли ради красного словца подменять понятия?
Ведь речь идет вовсе не о любой сложности, а об избыточной.


А критерием избыточной сложности является оберон. Это аксиома? Это понятие я "подменил"? Если не аксиома, то это требует каких-то доказательств, помимо рассуждений о принципе Калашникова.

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

for (i = 0; i < H; ++i)
    for (j = 0; j < W; ++j) {
        ...
        /* во вложенном цикле i не меняется, а W -- аргумент,
          неизменный внутри функции */
        ... + i * W + ...
        /* между прочим, в нашем процессоре нет встроенной операции
          умножения, так что здесь компилятор генерит вызов функции */
        ...
    }

Оптимизатор у нас на подходе, в данном конкретном случае все решаемо.
Раньше всегда рекомендовали выносить подобные повторные за пределы цикла (вынос инварианта):

for (i = 0; i < H; ++i) {
    int iW = i * W
    for (j = 0; j < W; ++j) {
        ...
        ... + iW + ...
        ...
    }
}

Но нынешняя программистская молодежь зачастую этого не делает.
Возможно, частично из-за спешки, частично "избалованная" оптимизирующими компиляторами на ПК.
Разумно ли в таких обстоятельствах практиковать однопроходные компиляторы?
Другой пример: индуктивные переменные в циклах.
Как их выявить за один проход?
Delayed code emission -- это, конечно, хорошо, но достаточно ли?

Как вы считаете, практичны ли однопроходные компиляторы в нынешних обстоятельствах?
Для меня это серьезный вопрос.

Ответ на »сообщение 1683« (pepper)
___________________________

Ответ на »сообщение 1679« (info21)
___________________________

>>4. Минимализм Оберона (в т.ч. исключение перечислимых типов) обусловлено не столько стремлением сохранить "чистоту идей Оберона" (хотя можно в каком-то смысле и так сказать, просто это будет косвенно), сколько четким пониманием того, что мы тут обозначили как "принцип Калашникова" -- "Избыточная сложность есть уязвимость".

Выкинь свой компьютер и купи счеты.

Эффектная фраза, конечно. :)
Но стоит ли ради красного словца подменять понятия?
Ведь речь идет вовсе не о любой сложности, а об избыточной.
В качестве школьного примера избыточной сложности можно привести геоцентрическую теорию, с ее эпициклами:
http://ru.wikipedia.org/wiki/Эпицикл
Избыточной сложностью страдает также архитектура некоторых компьютеров (отсюда растут корни другой метафоры применительно к Оберону: Оберон -- RISC в мире языков программирования).

Ответ на »сообщение 1685« (RBV)
___________________________


Не, если этот вопрос Вас не заинтересует, не пойдет.

Нет, не заинтересует.