Здравствуйте, VladD2, Вы писали:

VD>А ты с равнивай Оберон с C#. Вот тогла и поглядим где надежность выше.

Ну, что же, будем ожидать сообщений о программах, управляющих работой атомных станций, написанных на C#.

Здравствуйте, AVC, Вы писали:

AVC>Ну, что же, будем ожидать сообщений о программах, управляющих работой атомных станций, написанных на C#.

Или креститься от оных сообщений по поводу Оберона.

Откровенно говоря в атомных реакторах я бы вообще хотел видеть по меньше кода. И уж если он там необходим, то поменьше импиративного.

Ну, а что касается сравнения технологий, то это не аргумент. Еще раз повторюсь, что серьезное сравнеие Оберона с Шарпом приведет к явному краху рекламной компании Оберона.

VladD2,

> AVC>Ну, что же, будем ожидать сообщений о программах, управляющих работой атомных станций, написанных на C#.

> <...>

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

Имхо, как раз очень даже хороший аргумент. AVC, насколько я его понял, не говорит о том, что Оберон "лучше", чем C#, а вполне наглядно иллюстрирует важный момент, затрудняющий "серьезное" сравнение данных языков: у них разная область применения.

Здравствуйте, VladD2, Вы писали:

VD>А еще забавно будет глянуть на то как этот чудо переползет на второй фрэймворк где появятся дженерики. Вот будет забавно послушать Губанова, как он обоснует приклеивание такой некомпонетной вещи как дженерики к Оберону.

Я не спец в этом вопросе, но думаю при желании разработчики как-нибудь извернутся

Для того, чтобы оценить язык программирования, я знаю только один способ: понять, какую потребность пытается удовлетворить язык программирования, и как разработчик языка справляется с возникающими при этом проблемами.
Насколько я понимаю, цель разработки Оберона — создание простого и надежного языка системного программирования, поддерживающего объектно-ориентированное и компонентное программирование.
Для реализации этих целей Вирт в частности использовал раздельную компиляцию, сборку мусора и даже отказался от обычного понимания программы.
Эти и другие интересные решения я и предполагал обсудить, вовсе не ставя себе целью «сделать Оберону PR». Хотелось только объективно разобраться в его «плюсах» и «минусах». Ведь никто не думает, что Оберон «потеснит» другие языки на PC. У него другая «ниша». Поэтому и тему я сформулировал, на мой взгляд, скромно: «Есть ли плюсы у Оберона».
К сожалению, некоторые участники данного форума (и некоторых других форумов) набросились на Оберон с огульной критикой, не желая, как видно, ни на минуту вообразить, что существуют разные задачи и разные способы их решения. При этом «критика» не слишком разнообразна, постоянно делаются одни и те же утверждения.
Попытаюсь ответить на подобные критические замечания в одном посте.
Получается что-то вроде маленького опуса «Мифы и правда об Обероне».
Для удобства критику выделяю жирным шрифтом.

Оберон – это реинкарнация Паскаля.
Это не так. Паскаль и Оберон были созданы для совершенно разных целей.
Паскаль был задуман как язык обучения структурному программированию.
Оберон – язык системного программирования, его разработка была частью проекта по созданию рабочей станции Ceres. Так что Оберон наследует не Паскалю, а Модуле-2.
При этом Модула-2 была радикально переработа.
Меня именно и заинтересовало, как это было сделано.

В Обероне нет шаблонов. Какой ужас!
В Обероне действительно нет шаблонов и исключений.
Давайте разберемся.
Исключений нет, но ведь нет и утечки ресурсов. Вспомните, в каждом учебнике по Си++ пишут: не забудьте переопределить оператор копирования, если в классе есть члены-указатели. Это называется «глубокое копирование». А в Обероне – любое копирование «глубокое».
Шаблонов тоже нет. А для чего, кстати, они используются? Для реализации обобщенных (параметризованных) контейнеров и алгоритмов.
Можно ли реализовать их без шаблонов? Можно. Всякий помнит функции qsort и bsearch из стандартной библиотеки языка Си и потомков TCollection из популярного в районе 1990г. TurboVision. Подобные обобщенные контейнеры без шаблонов поставлялись в то же время практически со всеми коммерческими компиляторами Си++.
Есть ли в Обероне средства для их реализации, согласующиеся с его принципами безопасности? Есть. Хочу, например, обратить внимание на языковые конструкции IS и WITH. (Это называется type test и type guard.) В Компонентном Паскале (популярной версии Оберона) интересны с этой точки зрения родовые типы ANYREC и ANYPTR.
Какой основной аргумент выдвигается в пользу того, что без шаблонов «жить нельзя»? Их выразительность. Допустим. (Хотя для меня еще выразительнее неспособность компилятора Си++ выдать мало-мальски читабельное диагностическое сообщение о синтаксической ошибке при разборе шаблонов.) Но употребление шаблонов ведет к двум неприятным последствиям.
Во-первых, многократное дублирование кода, т.к. шаблоны каждый раз компилируются в отдельный код.
Во-вторых, ненадежность применения шаблонов. Допустим, мы нашли ошибку в реализации популярного шаблона. Казалось бы, «делов то»! Исправил ошибку и все, благо шаблон описан в одном месте. Да не все так просто. Надо перекомпилировать все программы, пользующиеся этим шаблоном. И как это обеспечить?
А в Обероне импортирующий модуль перекомпилировать не надо. Это называется раздельная компиляция. Именно этого и нет в языках с шаблонами. (Возможно, какие-то зачатки появились в C# 2.0; но там требуется «компиляция на лету», что не всегда приемлимо.)
Я, конечно, вовсе не противник шаблонов. Они хороши для своих целей и на своем месте (не в Обероне). Но надо помнить, что у каждой языковой конструкции есть своя цена.

Нужно быть профессиональной машинисткой, что бы вводить все эти BEGIN, END, PROCEDURE!
Неужели трудно настроить свой Vim так, чтобы все эти конструкции вводились одновременным нажатием пары клавиш?

Оберон – не язык промышленного программирования.
Утверждают, что популярные ныне языки программирования (C++, C#, Java) – языки промышленного программирования, а вот Оберон – нет.
Интересно получается. На Обероне – ПО для атомных станций, на Java – игрушки для мобильников. Вывод: Java – язык промышленного программирования, а Оберон – академическая игрушка.
Загадочное оно, это промышленное программирование!
Почему то вспоминается реплика из к/ф «В бой идут одни старики»:
«Первая эскадрилья у нас молодцы! Вот как «мессер» завалить, так это вторая. А как чего достать, так это первая!»

Оберон – «отстой», Вирт – “looser”.
«Критика – это когда глупый человек пишет об умном». (Л.Н.Толстой)

AVC,

> В Обероне нет шаблонов. Какой ужас!
> В Обероне действительно нет шаблонов и исключений.
> Давайте разберемся.
> Исключений нет, но ведь нет и утечки ресурсов.

Не очень понял, причем здесь утечки ресурсов... Мне интересно, а как предполагается сообщать об ошибках в Обероне, кодами возврата/модификацией глобальных переменных?

> Шаблонов тоже нет. А для чего, кстати, они используются? Для реализации обобщенных (параметризованных) контейнеров и алгоритмов.
> Можно ли реализовать их без шаблонов? Можно. Всякий помнит функции qsort и bsearch из стандартной библиотеки языка Си <...>

Но в C с этим были связаны определенные проблемы с проверками типизации. Как именно эти проблемы решаются в Обероне? В смысле, возможна ли статическая проверка типов в Обероне для подобных контейнеров и алгоритмов?

> Какой основной аргумент выдвигается в пользу того, что без шаблонов «жить нельзя»? Их выразительность. Допустим. (Хотя для меня еще выразительнее неспособность компилятора Си++ выдать мало-мальски читабельное диагностическое сообщение о синтаксической ошибке при разборе шаблонов.)

Это не является следствием определения языка, а является следствием реализации соответствующих компиляторов. Тот же EDG, на мой взгляд, выдает вполне внятные сообщения об ошибках при инстанцировании шаблонов.

> Но употребление шаблонов ведет к двум неприятным последствиям.
> Во-первых, многократное дублирование кода, т.к. шаблоны каждый раз компилируются в отдельный код.

Это тоже далеко не обязательно: некоторые компиляторы умеют "сливать" идентичные специализации, плюс есть техники, как добиваться, чтобы код не "пух", даже если компилятор этого делать не умеет.

> Во-вторых, ненадежность применения шаблонов. Допустим, мы нашли ошибку в реализации популярного шаблона. Казалось бы, «делов то»! Исправил ошибку и все, благо шаблон описан в одном месте. Да не все так просто. Надо перекомпилировать все программы, пользующиеся этим шаблоном. И как это обеспечить?

Ну, тут может быть более чем одна точка зрения на то, какой вариант надежнее: перекомпилировать весь код, использующий шаблоны, либо же протестировать, чтобы выяснить что та же диагностика не выдается во время исполнения, если статических проверок, как в случае шаблонов, нет.

Здравствуйте, AVC, Вы писали:
AVC>В Обероне нет шаблонов. Какой ужас!
AVC>В Обероне действительно нет шаблонов и исключений.
AVC>Давайте разберемся.
AVC>Исключений нет, но ведь нет и утечки ресурсов. Вспомните, в каждом учебнике по Си++ пишут: не забудьте переопределить оператор копирования, если в классе есть члены-указатели. Это называется «глубокое копирование». А в Обероне – любое копирование «глубокое».

Исключения нужны из-за утечки ресурсов? И как же они помогают в борьбе с ними? Наоборот, во многих языках вводятся дополнительные конструкции (using, finally) чтоб избежать утечек при работе с исключениями. На мой взгляд исключения нужны чтоб можно было прервать поток исполнения и оповестить вызывающего о причинах.

Мне вот что интересно. Как в Оберон будет выглядеть аналог такого кода?

void Func1()
{
  try
  {
    Func2();
  }
  catch(SomeException e)
  {
     // обрабатываем исключение при этом у нас есть доступ к someData
  }
}

void Func2() { Func3(); } // исключения не требуют написания какого либо кода на всех уровнях вызова.

void Func3()
{
  ...
  if(someConditions)
    throw new SomeException(someData);
  ...
}

AVC>Нужно быть профессиональной машинисткой, что бы вводить все эти BEGIN, END, PROCEDURE!
AVC>Неужели трудно настроить свой Vim так, чтобы все эти конструкции вводились одновременным нажатием пары клавиш?

Этот вопрос конечно не принципиальный и грамотная IDE сама нарисует все эти BEGIN, END etc. Только все равно останется толпа лишних буковок. Многим это не нравиться.

AVC>Оберон – не язык промышленного программирования.
AVC>Утверждают, что популярные ныне языки программирования (C++, C#, Java) – языки промышленного программирования, а вот Оберон – нет.
AVC>Интересно получается. На Обероне – ПО для атомных станций, на Java – игрушки для мобильников. Вывод: Java – язык промышленного программирования, а Оберон – академическая игрушка.
AVC>Загадочное оно, это промышленное программирование!
AVC>Почему то вспоминается реплика из к/ф «В бой идут одни старики»:
AVC>«Первая эскадрилья у нас молодцы! Вот как «мессер» завалить, так это вторая. А как чего достать, так это первая!»

Промышленность нашем случае ИМХО это вовсе не энергетика а IT. Точнее та ее часть, что занимается Software Development. Так вот промышленным может считаться язык, который массово используется в нашей с вами промышленности. Поэтому тот факт, что Java используется для написания программ для мобильных устройств как раз говорит о том, что это язык промышленного (читай массового) использования. Оберон пока может похвастаться только фактами единичного применения. Если хотяб пол процента создаваемого кода буден написано на Оберон тогда и включим его в список промышленных языков.

AVC>Оберон – «отстой», Вирт – “looser”.
AVC>«Критика – это когда глупый человек пишет об умном». (Л.Н.Толстой)

Тут согласен.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК> Не очень понял, причем здесь утечки ресурсов...

Например, блок try ... finally ... end нужен именно для того чтобы "прибрать за собой если вдруг нагадил". В то время как в языке со сборщиком мусора прибирать за собой не нужно.

ПК> Мне интересно, а как предполагается сообщать об ошибках в Обероне, кодами возврата/модификацией глобальных переменных?

1) О каких еще ошибках?
2) Кому сообщать?

Ели об ошибках в алгоритме программы, то сообщать надо программисту — для этого есть ASSERT() и HALT().

Здравствуйте, GarryIV, Вы писали:

GIV>Мне вот что интересно. Как в Оберон будет выглядеть аналог такого кода?

Прямого аналога нет. Впрочем, если Вы объясните смысл приведенного Вами кода, то, быть может, я смогу рассказать Вам как это сделать без использования механизма исключений.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Имхо, как раз очень даже хороший аргумент. AVC, насколько я его понял, не говорит о том, что Оберон "лучше", чем C#, а вполне наглядно иллюстрирует важный момент, затрудняющий "серьезное" сравнение данных языков: у них разная область применения.

Совершенно верно. Я вовсе не утверждаю, что Оберон лучше других языков во всех случаях. И не собираюсь отнимать у программистов любимые ими инструменты.
Моей целью изначально было только обсуждение некоторых решений, принятых Виртом при разработке Оберона.
Но, к сожалению, я прихожу к выводу, что не все способны к спокойному и объективному обсуждению. Например, я не понимаю с каким именно моим утверждением спорит Vlad2. Он только повторяет, что C# лучше, чем Оберон. Видимо, во всех случаях, для любых целей. Вообще нет попытки понять логику построения Оберона.
Зачем тогда вообще постить, если он это уже высказал раз двести, употребляя выражения вроде "Оберон — это ЛАЖА"?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Например, блок try ... finally ... end нужен именно для того чтобы "прибрать за собой если вдруг нагадил". В то время как в языке со сборщиком мусора прибирать за собой не нужно.

Именно поэтому в C++ try/finally нет, и в общем-то и не нужны, а в Java без них никуда

И вообще, try/catch/finally — это средство обработки ошибок, а не "прибирания за собой".

Здравствуйте, GarryIV, Вы писали:

GIV>Исключения нужны из-за утечки ресурсов? И как же они помогают в борьбе с ними? Наоборот, во многих языках вводятся дополнительные конструкции (using, finally) чтоб избежать утечек при работе с исключениями. На мой взгляд исключения нужны чтоб можно было прервать поток исполнения и оповестить вызывающего о причинах.

Если бы дело обстояло так, как Вы утверждаете, вполне хватало бы старых добрых setjmp и longjmp. Ведь longjmp именно возвращает управление и код ошибки.
Как помогают исключения? Возьмем самый простой, "набивший оскомину" пример: шаблон auto_ptr чистит кучу (т.е. собирает мусор) в случае, если было выброшено исключение. Так и надо делать в Си++.
Но (imho) это не самое простое и не самое системное решение проблемы утечки ресурсов. Например, шаблон auto_ptr не стоит использовать в стандартных контейнерах STL. Это даже запрещается делать.
И, сравните, насколько проще решается эта проблема в виртовском Обероне.
(Специально оговариваюсь: я не считаю, что Оберон лучше других языков всегда и во всем.)

GIV>Мне вот что интересно. Как в Оберон будет выглядеть аналог такого кода?
GIV>

GIV>void Func1()
GIV>{
GIV>  try
GIV>  {
GIV>    Func2();
GIV>  }
GIV>  catch(SomeException e)
GIV>  {
GIV>     // обрабатываем исключение при этом у нас есть доступ к someData
GIV>  }
GIV>}

GIV>void Func2() { Func3(); } // исключения не требуют написания какого либо кода на всех уровнях вызова.

GIV>void Func3()
GIV>{
GIV>  ...
GIV>  if(someConditions)
GIV>    throw new SomeException(someData);
GIV>  ...
GIV>}
GIV>

Сначала хотелось бы понять, для решения какой задачи требуется такой замечательный код.

GIV>Промышленность нашем случае ИМХО это вовсе не энергетика а IT. Точнее та ее часть, что занимается Software Development. Так вот промышленным может считаться язык, который массово используется в нашей с вами промышленности. Поэтому тот факт, что Java используется для написания программ для мобильных устройств как раз говорит о том, что это язык промышленного (читай массового) использования. Оберон пока может похвастаться только фактами единичного применения. Если хотяб пол процента создаваемого кода буден написано на Оберон тогда и включим его в список промышленных языков.

Наверное, здесь надо просто уточнить термины. Возможно, тогда выяснится, что и спора нет, что он — только терминологический.
Что, на Ваш взгляд, "промышленнее": АЭС или "мобильник"? Ведь АЭС гораздо меньше, чем мобильников.

Здравствуйте, WFrag, Вы писали:

WF> Именно поэтому в C++ try/finally нет

Как это нет, если есть? Они там ВЕЗДЕ есть. И раз они там уже везде есть, то и смысла вводить еще одно ключевое слово finally — уже нет. ЛЮБОЙ блок {} в Си++ по смыслу и есть try/finally — так как все деструкторы локальных объектов должны быть вызваны при выходе из блока даже тогда когда выход из него осуществляется в аварийном режиме.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Как это нет, если есть? Они там ВЕЗДЕ есть. И раз они там уже везде есть, то и смысла вводить еще одно ключевое слово finally — уже нет. ЛЮБОЙ блок {} в Си++ по смыслу и есть try/finally — так как все деструкторы локальных объектов должны быть вызваны при выходе из блока даже тогда когда выход из него осуществляется в аварийном режиме.

Ладно, это философский вопрос. Оставим его.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Не очень понял, причем здесь утечки ресурсов... Мне интересно, а как предполагается сообщать об ошибках в Обероне, кодами возврата/модификацией глобальных переменных?

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

>> Шаблонов тоже нет. А для чего, кстати, они используются? Для реализации обобщенных (параметризованных) контейнеров и алгоритмов.
>> Можно ли реализовать их без шаблонов? Можно. Всякий помнит функции qsort и bsearch из стандартной библиотеки языка Си <...>

ПК>Но в C с этим были связаны определенные проблемы с проверками типизации. Как именно эти проблемы решаются в Обероне? В смысле, возможна ли статическая проверка типов в Обероне для подобных контейнеров и алгоритмов?

Такая проверка в Обероне не только возможна, но обязательна. Компилятор Оберона просто не позволит Вам обойти такую проверку, и его не обманешь "приведением типов".
Для этого используюся такие средства языка как type test (конструкция IS) и type guard (конструкция WITH).

>> Какой основной аргумент выдвигается в пользу того, что без шаблонов «жить нельзя»? Их выразительность. Допустим. (Хотя для меня еще выразительнее неспособность компилятора Си++ выдать мало-мальски читабельное диагностическое сообщение о синтаксической ошибке при разборе шаблонов.)

ПК>Это не является следствием определения языка, а является следствием реализации соответствующих компиляторов. Тот же EDG, на мой взгляд, выдает вполне внятные сообщения об ошибках при инстанцировании шаблонов.

IMHO, тот факт, что компиляторы (пусть не все) даже очень крупных производителей (например, MSVC) не могут дать внятного сообщения об ошибке, говорит о том, что язык слишком усложнен.

>> Но употребление шаблонов ведет к двум неприятным последствиям.
>> Во-первых, многократное дублирование кода, т.к. шаблоны каждый раз компилируются в отдельный код.

ПК>Это тоже далеко не обязательно: некоторые компиляторы умеют "сливать" идентичные специализации, плюс есть техники, как добиваться, чтобы код не "пух", даже если компилятор этого делать не умеет.

Да, существуют такие техники. Самый простой пример: использование косвенных контейнеров с inline функциями приведения void* к конкретному типу указателя.
Но во многих случаях такие техники еще не изобретены.

>> Во-вторых, ненадежность применения шаблонов. Допустим, мы нашли ошибку в реализации популярного шаблона. Казалось бы, «делов то»! Исправил ошибку и все, благо шаблон описан в одном месте. Да не все так просто. Надо перекомпилировать все программы, пользующиеся этим шаблоном. И как это обеспечить?

ПК>Ну, тут может быть более чем одна точка зрения на то, какой вариант надежнее: перекомпилировать весь код, использующий шаблоны, либо же протестировать, чтобы выяснить что та же диагностика не выдается во время исполнения, если статических проверок, как в случае шаблонов, нет.

Конечно, точек зрения может быть несколько.
Но мне кажется, что Вы недооцениваете масштаб последствий того, что код, содержащий ошибку, успел разбежаться по тысячам (а для Си++ даже миллионам) отдельных (stand-alone) программ. Они уже откомпилированы, их размноженные копии уже проданы пользователям, и от того, что мы все-таки нашли и исправили ошибку в шаблоне (скорее всего, в каком-нибудь h-файле) пользовательские копии правильными не стали.
Можно было бы надеяться на рассылку "патчей", но на практике этим воспользуются очень немногие "продвинутые" пользователи.
Слава богу, что подавляющее большинство программ, написанных на "промышленных" (языках Си++, Java и C#) на самом деле применяются в сфере услуг, а не в промышленной сфере.

Вообще авторы Оберона вовсе не отрицают пользы родовых типов. Тот же Szyperski сделал пробную реализацию в 97. Просто там где применялся Оберон они не требовались. Сейчас "параметризированные типы" введены в OOC.

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

PROCEDURE Main;
  PROCEDURE Handler (VAR e: SomeException);
  BEGIN
      IF … the failure can be repaired … THEN
       …Repair it…;
      Exceptions.Resume (* return using resume semantics*)
      END;
      (* return using terminate semantics*)
   END Handler;
BEGIN
  ...
  Exceptions.Raise(e);
  ...
END.

GIV>Промышленность нашем случае ИМХО это вовсе не энергетика а IT. Точнее та ее часть, что занимается Software Development. Так вот промышленным может считаться язык, который массово используется в нашей с вами промышленности.
Промышленность, она разная бывает. А разработка, скажем, бортового ПО для ракеты это уже не Software Development? И причем здесь массовость? Это скорее критерий "популярного", а не "промышленного" языка.
Что касается милого вашему сердцу IT. Живет себе такой Stefan Metzeler. Он не бегает по собеседованиям и не рассылает резюме. Вместо этого он в одиночку реализовал порядка 20 проектов за 8 лет. И все на Обероне. И плевать ему на то сколько человек пишут на С++,Java и т.п. Между прочим, среди клиентов: DuPont, Hewlett Packard, ABB, IBM, Royal Bank of Canada, Logitech...

Т>Что касается милого вашему сердцу IT. Живет себе такой Stefan Metzeler. Он не бегает по собеседованиям и не рассылает резюме. Вместо этого он в одиночку реализовал порядка 20 проектов за 8 лет. И все на Обероне. И плевать ему на то сколько человек пишут на С++,Java и т.п. Между прочим, среди клиентов: DuPont, Hewlett Packard, ABB, IBM, Royal Bank of Canada, Logitech...

"Если звезды зажигают, то значит, это кому-нибудь нужно" (с)

Созданный и доведенный до ума язык будет где-нибудь, да востребован. ИМХО

Здравствуйте, Трурль, Вы писали:

Т>Живет себе такой Stefan Metzeler.

Это тот самый? http://www.amadeus-3.com/

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Это тот самый? http://www.amadeus-3.com/
Ага,тот самый. Он еще в свободное время свой Amadeus пописывал.
А вот парочка цитат с его сайта.

Canada and the UK (and probably other countries as well) strictly prohibit the use of C and C++ for developments related to any nuclear application. The only languages which were accepted were Ada and Modula-2, thanks to the fact that it had become the only programming language with full ISO standardisation (a very complex process) and certified compilers.

How important is NOTATION?
Fundamental !!!
Try using Roman Numerals for arithmetic calculations.

According to the director of technology of a large US corporation, the average time to train a new C++ programmer is about 3 years, "Which is kind of embarrassing" he added, "since NASA only takes 18 months to train an astronaut."

Some time ago, I did some consulting work for Deutsche Bank and had a chance to work with their development team. When I browsed through the code of their main trading application, it took me a while to figure out that it was actually C++. It looked more like Java or in fact Modula-2, apart from the accolades. Talking to the project leader, I learned that they had very strict guidelines for programming:
— one instruction per line
— every instruction with comment
— NO Multiple inheritance
— NO Macros
— NO Generic modules
— NO Overloading
— NO fancy C-style expressions, only basic operators
— Naming conventions strictly enforced

Здравствуйте, Трурль, Вы писали:

Т>

How important is NOTATION?
Т>Fundamental !!!
Т>Try using Roman Numerals for arithmetic calculations.