С наступающим!
И пусть в Новом Году форумы в Королевстве будут такими же полезными и увлекательными для всех, имеющих отношение к этой профессии.

Ответ на »сообщение 1434« (Geniepro)
___________________________
Всех с наступающим!!!

Такие баталии вокруг С++... :о))

Мне понравилась статья Евгения Зуева "Редкая профессия" о том, как он в середине 90-х занимался разработкой компилятора С++ для какой-то европейской фирмы...
Весьма интересно и поучительно.

ЗЫ. С компилятором Оберона они бы наверняка справились бы на порядок быстрее, чем с С++.

ЗЗЫ. Действительно, С Новым Годом, коллеги!

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


>>>Отсутствие такого элемента скорее подчеркивает общую бедность и невыразительность.
В таких случаях принято добавлять, что это всего лишь Ваше мнение и не более.


Все, что я говорю на этом форуме, является моим личным мнениенм.

P.S. Так же как и поздравления с Новым Годом - лично от меня :)

Замечание для тех, кто считает языки С/С++ "надежными" и "безопасными" языками. Вот что говорят сами авторы языка С по поводу оператора switch:
"Проход через варианты носит ПРОТИВОРЕЧИВЫЙ характер... Проход из одного варианта в другой - вещь НЕНАДЕЖНАЯ; в случае модификации программы это может привести к РАЗВАЛУ ее работы. За исключением многих меток для одного вычисления, проходом через варианты следует пользоваться весьма ОСТОРОЖНО" - конец цитаты.
(Б.Керниган, Д.Ритчи-Язык программирования С.М.,Финансы и Статистика, 1985).
"Отличный" язык, инструкции к которому очень напоминают инструкции для сапера перед операцией разминирования минных полей :))

Хочу добавить еще один комментарий к вопросу о "бедности и выразительности" языка программирования.
Давным-давно (:)) когда были только 3 "основных подхода к программированию" с именами "Basic", "Pascal", "C", мне очень понравилась в Паскале Вирта реализация такого математического понятия, как "множество". При всей свой ограниченности (множество только конечное, мощность<=255) эта реализация показалась мне, человеку, который очень ценит математический "фундамент" в программировании, очень удачным решением. Действительно, понятия числа и множества - это фундамент всей математики. Почему понятию "число" повезло, а понятие "множество" оказалось изгоем? Во всех языках, кроме Паскаля и его наследников, где оно хоть и в "урезанном" виде, но существует. С необходимыми теоретико-множественными операциями - объединением, пересечением, дополнением.
Как красиво в Паскале выглядит что-нибудь вроде:
Type
Colors = (black, white, red, yellow, green, blue, magenta);
Palette = Set of Colors;
Var
  p: Palette;
К чему это я? А к тому, что если "проблема перечислимого типа" так сильно волнует критиков Оберонов, то лучшим языком по этому критерию следует признать Паскаль, а вовсе на С/C++. В этом языке Вы можете определить такие типы данных, как "Множество цветов" и, даже, "Множество белых медведей". Причем на уровне обычных стандартных типов, без всяких классов и прочих последних новомодных изобретений. Так что насчет особой "выразительности" языков типа C/C++ и их наследников лучше помолчать. Против выразительности языков виртовской школы они "не катят".
Мое мнение, конечно :).

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


>>Я не понимаю, почему такое внимание уделяется перечислимому типу, весьма малозначительному элементу системы типов.

Только потому, что все хорошо представляют, что это такое, и проще показать на простых примерах его востребованность. Лично я не считаю отсутствие перечислимого типа самым страшным грехом оберона :) Отсутствие такого элемента скорее подчеркивает общую бедность и невыразительность.

У меня нет такого впечатления, несмотря на то, что пишу на Си++, языке весьма "выразительном".
А какие более серьезные претензии к Оберону?
Мы тут некоторое время назад сокрушались, что в Обероне нет дженериков (хотя еще в 90-х годах Шиперски предлагал интересный вариант "легкого" полиморфизма).


>>ИМХО, гораздо интереснее и принципиальнее (старый уже) вопрос Сергея Перовского, что может дать Оберон программистам "традиционных" stand-alone приложений со статической линковкой.

Илья Ермаков упоминал о другом подходе к разработке (не отредактировал/скомпилировал/запустил), но подробнее не описал.

Вероятно, речь идет о том, что часто достаточно перекомпилировать и перегрузить один единственный модуль (экономия времени).
Другой момент.
Я сравниваю Оберон в основном с Си и Си++, др. своими рабочими языками.
Я уж сейчас не говорю о том факте, что VC выдает сообщения "INTERNAL COMPILER ERROR".
Просто предлагаю подумать, как в Си/Си++ контролируется целостность проекта.
Один способ -- перекомпилировать весь проект целиком. Есть ли другой?


>>Что касается вопроса о том как сравнивать сложность языков, думается есть достаточно простой и объективный критерий: размер компилятора и скорость его самокомпиляции. (Если не ошибаюсь, Вирт применял этот критерий.)

Сдается мне, что по такому критерию всех сделает какой-нибудь лисп ;)

Скорее даже Форт. :)
Но здесь, ИМХО, уже работает вторая часть фразы: "Делай настолько просто, насколько возможно, но не проще."

Ответ на »сообщение 1428« (Jean)
___________________________
Тут еще такое дело - в этой ветке неоднократно выяснялось, что люди оценивают "выразительность" для принципиально различных задач. Не будем забывать, что Оберон идеально заточен под системное программирование (только вот не надо начинать путать системное с низкоуровневым) в широком смысле - т.е. под создание ОС, инструментального ПО, компонентных Framework-ов, которые потом используются прикладниками. Оберон (и особенно, на мой взгляд, - Компонентный Паскаль) позволяет очень красиво и ясно воплощать архитектурные решения. В этом аспекте ему равных нет. Т.е. 1) выразителен архитектурно.
Однако Оберон - апогей императивных языков в чистом виде, и поэтому можно придираться к отсутствию каких-то "фенечек", тем, что из языка не сделали "винегрет" с функциональными примочками и т.п. Тем не менее, и для целого ряда прикладных задач Оберон очень эффективен, неспроста его так обожают ученые, хотя, казалось бы, чем им Maple, Хацкель и прочие не катят... Точно сформулировать можно так - для прикладных задач, сложных интенсивно, т.е. за счет сочетания сложной логики и требований к гибкости и быстродействию. Т.е. 2) выразителен в алгоритмике. Казалось бы, в чем тут язык может превосходить другие современные языки - программирование "в малом" - оно и в Африке, как говорится... Тут 2 аспекта: строгий синтаксис, не позволяющий "выкрутасов", дает а) простые и красивые решения б) уменьшает кол-во ошибок в) дает единообразие, что тоже немаловажно - всему Оберон-сообществу очень легко придерживаться единого стиля, а каждому конкретному программисту меньше ломать голову, каким из двух равноценных путей пойти, поскольку из множества эквивалентных вариантов, которые в других языках оставляются "по вкусу", из пустого популизма, Виртом некогда было оставлено по одному, на основе собственного опыта.
Второй аспект - те ошибки, которые все-таки допущены - вылавливаются очень быстро. Это - по собственному опыту разработок в Блэкбоксе. Мне приходится до сих пор участвовать в крупном проекте на С++, и после Блэкбокса отлаживаться в Visual Studio - как ловить черную кошку в нескольких темных комнатах - ставить мышеловки там и тут и надеяться, что кошка таки в них попадется. В ББ за счет мощного рантайма я в каждый момент времени полностью контролирую работающую систему, могу мгновенно добраться до каждого уголка в ее состоянии, просто щелкая мышкой по ссылкам в структурном дампе. Появление ошибочных данных мгновенно "срезается" на каком-либо из неотключаемых ASSERT-ов, а далее - внимательно просматриваем все состояние приложения, которое у нас как на ладони, и очень хорошо думаем. После нескольких минут думания ошибка обычно устраняется. Сравните с работой цеплюсистов - часами гонять в пошаговой отладке, потом вдруг понять, что гоняем совсем не по тому месту, а ошибка возникла на 100 метров ранее, - и гонять еще столько же по тому месту...
Также не боимся работать со сложными динамическими структурами данных - сборка мусора, - ну, это понятно, это и в Яве, и в Шарпе есть. Но в Яве есть оборотная сторона медали - все ООП динамическое, в результате, когда мы хотим сделать мелкие короткоживущие типы объектными, приходится все время помнить о накладных расходах на выделение/сборку памяти. В Обероне используем статические ОО-записи точно так же, как и динамические. Поэтому вся система GUI-сообщений полностью объектно-ориентирована и работает очень эффективно, без динамического выделения памяти.
Итого - теперь, наверное, понятно, почему для интенсивно сложных прикладных задач Оберон катит так же, как и для системных.
Остаются экстенсивно сложные задачи, часто характерные для бизнеса, сложные не логикой, а объемом и статическими связями из предметной области. Вот тут я еще могу понять жалобы на "невыразительность" - декларатива в языке будет не хватать для прямого выражения этих связей и нюансов в коде, а в остутствие "фенечек" пораскинуть головой для поиска более простых решений времени не хватает из-за сжатых сроков, - ну так используйте предметно-ориентированные или суррогатные языки типа Шарпов - и не парьтесь. Точно то же - если ваши задачи красиво решается функциональным образом и вы не гонитесь за сверхбыстродействием.

>>>"Нормальным" это не считается. "Законно" это постольку поскольку...
Законно, но не нормально. Классический образец демагогии и игры словами.

>>>Отсутствие такого элемента скорее подчеркивает общую бедность и невыразительность.
В таких случаях принято добавлять, что это всего лишь Ваше мнение и не более.

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


Этот "кошмар" с точки зрения грамматических норм языка считается "нормальным" и "законным". В этой ситуации увольнять надо язык :)


"Нормальным" это не считается. "Законно" это постольку поскольку язык C - это "переносимый ассемблер" и был изобретен во времена, когда структурное программирование только начинало свое победное шествие.