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

СГ>Здравствуйте, FR, Вы писали:

FR>>А вот мне кажется что ему придется мучатся выражая предметную область на более бедном языке.

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

Для чего?
Сергей, заканчивай мысли, чтобы логика была, а то получаются только пустые слова, не более.

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

D>Сергей, это вы что-то преувеличили... Компилятору в данном случае нет необходимости искать определение этой функции, ему вообще ничего не надо искать. Функция объявлена, сигнатура известна, компилятор просто вставит в объектный модуль ссылку на эту сигнатуру, а искать её будет уже компоновщик (линкер). И, кстати, поскольку компоновщику нет нужды делать синтаксический анализ, поскольку компоновщик получает уже готовые сигнатуры "на блюдечке", то связывание функций не будет трудоёмким.

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

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

LVV>> уверяю, вирт не написал ни строчки — сам такой руководитель, знаю

Неправда ваша: Michael Franz, Oberon — The Overlooked Jewel, раздел 2.

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

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

K_O>И коль уж воскресили древнюю тему, то повторюсь: мне не нравится, что в вышеприведенном примере операции над элементами массива выглядят точно также как и над одиночными переменными. Более того, то выражение, выглядящее как обычное математическое выражение над несколькими переменными на самом деле мало того, что работает с эелементами массивов, так еще и внутри себя содержит цикл.

Знаешь, посылать друг-друга не вежливо и не профессионально, но не могу удержаться, чтобы не послать тебя посмотреть на MatLab, на признанного лидера среди математических инструментов. Там операции над векторами и матрицами именно так и записываются, в обычном виде, почти как профессором на доске на лекции по вышке.

Всем это кажется удобным, хотя твое мнение, очевидно, иное.

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

К>Для чего?
К>Сергей, заканчивай мысли, чтобы логика была, а то получаются только пустые слова, не более.

Для написания программ общего назначения, разумеется. Самый первый Оберон-1 можно рассматривать как кросплатформенный крос-архитектурный объектно ориентированный ассемблер на базе которого можно создавать новые расширения языка более удобные для той или иной предметной области.

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

СГ>Здравствуйте, Курилка, Вы писали:

К>>Для чего?
К>>Сергей, заканчивай мысли, чтобы логика была, а то получаются только пустые слова, не более.

СГ>Для написания программ общего назначения, разумеется. Самый первый Оберон-1 можно рассматривать как кросплатформенный крос-архитектурный объектно ориентированный ассемблер на базе которого можно создавать новые расширения языка более удобные для той или иной предметной области.

Ну коли они достаточные, то скажи тогда по твоему примеру — как на нём реализуется функциональность аналогичная шаблонам C++?
Вот это уже покажет какую-то "достаточность" (хотя и не докажет), а простыми заявлениями и я кидаться могу, факты важнее, имхо.

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

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

Сергей, поправка принимается, но мне хотелось бы отметить ещё два момента:

1. Линковка не создаёт тормозов. Реально. Конечно, это зависит от проекта к проекту, но по моим субъективным ощущениям вряд ли линковка будет занимать более 10% от общего времени компиляции проекта. Это довольно быстрая и не накладная процедура.
   
   
2. В любом случае линковка выполняется всего один раз. Её не нужно делать всякий раз при запуске программы. А если один раз, то время, затраченное на ликовку вообще становится несущественным (в разумных пределах). Скажем, лично меня не напрягут лишние 5 секунд, если я знаю, что это нужно сделать всего один раз.

Что же происходит в "модульных" языках? Да то же самое, совершенно то же самое. С той лишь разницей, что все имена (сигнатуры) в них разбиты на группы, которые относятся к разным модулям.

На самом деле, в С++ есть понятие namespace, которое позволяет точно так же разбивать названия функций на группы. Да и для функций-членов класса, если угодно в сигнатуре учитывается название класса.

Так что в этом вопросе "модульные" языки не имеют никакого преимущества.

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

K_O>>И коль уж воскресили древнюю тему, то повторюсь: мне не нравится, что в вышеприведенном примере операции над элементами массива выглядят точно также как и над одиночными переменными. Более того, то выражение, выглядящее как обычное математическое выражение над несколькими переменными на самом деле мало того, что работает с эелементами массивов, так еще и внутри себя содержит цикл.

V>Знаешь, посылать друг-друга не вежливо и не профессионально, но не могу удержаться, чтобы не послать тебя посмотреть на MatLab, на признанного лидера среди математических инструментов. Там операции над векторами и матрицами именно так и записываются, в обычном виде, почти как профессором на доске на лекции по вышке.

V>Всем это кажется удобным, хотя твое мнение, очевидно, иное.

Я давно не пользовался MathLab, поэтому могу ошибаться, однако, насколько я помню данный продукт является специализированной системой для обработки математических выражений: взятие интегралов в аналитическом виде, решение огромных СЛАУ, решение дифференциальных уравнений больших порядков, вычисление пределов и проч., т.е. то, что математик (физик, химик, ученый или инженер другой специальности) вычислит и сам на бумажке, но у него на это уйдет много времени. Цель данного продукта — сэкономить время на решении трудоемких математических задач. Отсюда — иные средства, иной язык более удобный для математика, нежели для программиста, иные особенности. Математику достаточно знать, что вот это — матрица, с такими-то значениями, и требуемая операция над ней должна быть выполнена за относительно приемлемое время. А для ряда задач время выполнения вообще роли не играет — лишь бы посчиталось.

Тогда как мне, как программисту важно знать, как эта матрица представлена в памяти, какой тип данный у ее элементов, какими конкретно значениями она проинициализирована (и от этого тоже может зависеть алгоритм вычислений), как быстро над ней будет выполнена требуемая операция, что я смогу изменить, если время вычислений перестанет меня устраивать. Пример, о котором я говорю, большинство требуемой информации от меня скрывает.

Так что твой пример неудачный, с языками программирования общего назначения имеет мало общего.

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

К>но ты давай нормальный пример

WITH используется в обработчиках сообщений. Пусть тип View — потомок от базового типа у которого есть (виртуальный) абстрактный метод HandleMsg (VAR msg: Message), где Message — базовый тип сообщений. Тогда реализация этого метода может быть такой:

PROCEDURE (v: View) HandleMsg (VAR msg: Message);
BEGIN
  WITH 
    msg: SomeMsg    DO ... ля-ля-ля ... |
    msg: AnotherMsg DO ... трали-вали...|
    ELSE (* игнорирование всех остальных сообщений *) 
  END;
END HandleMsg;

Где типы SomeMsg и AnotherMsg есть расширения (потомки) типа Message.

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

К>Ну коли они достаточные, то скажи тогда по твоему примеру — как на нём реализуется функциональность аналогичная шаблонам C++?
К>Вот это уже покажет какую-то "достаточность" (хотя и не докажет), а простыми заявлениями и я кидаться могу, факты важнее, имхо.

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

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

D>
1. Линковка не создаёт тормозов. Реально. Конечно, это зависит от проекта к проекту, но по моим субъективным ощущениям вряд ли линковка будет занимать более 10% от общего времени компиляции проекта. Это довольно быстрая и не накладная процедура.
   
   D>
2. В любом случае линковка выполняется всего один раз. Её не нужно делать всякий раз при запуске программы. А если один раз, то время, затраченное на ликовку вообще становится несущественным (в разумных пределах). Скажем, лично меня не напрягут лишние 5 секунд, если я знаю, что это нужно сделать всего один раз.

О, как вы неправы, создает и еще как! Для больших С++ проектов после появления IncrediBuilda это — самый больной вопрос. Линковка в течении 40 минут на современном компе — это далеко не фантастика. Более того, это один из главных тормозов в разработке сложных систем. Проверено на собственной шкуре.

D>Что же происходит в "модульных" языках? Да то же самое, совершенно то же самое. С той лишь разницей, что все имена (сигнатуры) в них разбиты на группы, которые относятся к разным модулям.

Нет, в модульных языках есть одно существенное отличие — информация о типах данного модуля содержится в скомпилированных объектных файлах. Эта информация доступна компилятору при компиляции другого модуля, который содержит секцию импорта из другого модуля. В результате — каждая строка в исходном тексте программы обрабатывается компилятором ровно один раз.
А теперь вопрос: сколько раз при компиляции большого С++ проекта компилятор обрабатывает, скажем, файл stdio.h?

D>На самом деле, в С++ есть понятие namespace, которое позволяет точно так же разбивать названия функций на группы. Да и для функций-членов класса, если угодно в сигнатуре учитывается название класса.

Namespace решает только проблему конфликтов имен, к организации процесса компиляции он отношения не имеет.

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

D>Кроме того, вопрос Дарнея касался немного другого. Если я его правильно понял, он засомневался, что в отсутствие Паскаля мы работали на Алголе-68 и предположил, что мы все работали бы на С (С++).

Я говорил именно об этом. Роль паскаля в современной индустрии близка к нулю, так что его отстутствие не повлияло бы практически ни на что. Может быть только, еще больше склонило бы чашу весов в сторону C/C++

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

СГ>А Вы хоть знаете что такое оператор WITH? Или это Вы взяли with из того паскаля, который был сразу после Алгола?

из того самого паскаля, который использует на порядок большее количество людей, чем Оберон — из Object Pascal AKA Delphi.

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

СГ>А еще тормоза компиляции происходят из-за того что в Си/Си++ можно влюбом месте программы написать:
СГ>

СГ>{
СГ>  extern void XerZnaetKakayaFunkciyaFigZnaetGdeOnaOpredelena();
СГ>  XerZnaetKakayaFunkciyaFigZnaetGdeOnaOpredelena();
СГ>}
СГ>

СГ>(Кстати, по смыслу это очень близко к инструкции goto) Компилятор замучается бегать по всем файлам проекта и искать где же определена эта функция (причем ему еще надо убедиться в том что эта функция определена не более одного раза). А в модульных языках программирования компилятор с самого начала знает из какого модуля какая функция вызывается и не тратит время на ее поиск.

ну это — просто хит. Сразу выдает глубочайшие познания о принципах работы компиляторов вообще и компилятора С++ в частности

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

K_O>О, как вы неправы, создает и еще как! Для больших С++ проектов после появления IncrediBuilda это — самый больной вопрос. Линковка в течении 40 минут на современном компе — это далеко не фантастика. Более того, это один из главных тормозов в разработке сложных систем. Проверено на собственной шкуре.

Да, механизм компиляции в С++ устарел до безобразия. С этим никто не спорит.
Кстати а что мешает в таком крупном проекте заюзать dll?

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

СГ>Здравствуйте, Курилка, Вы писали:

К>>Ну коли они достаточные, то скажи тогда по твоему примеру — как на нём реализуется функциональность аналогичная шаблонам C++?
К>>Вот это уже покажет какую-то "достаточность" (хотя и не докажет), а простыми заявлениями и я кидаться могу, факты важнее, имхо.

СГ>Ну, знаете...., перефразируя фразу Клюева об абстракциях, скажу что шаблоны ради шаблонов нам не нужны. Шаблоны не добавляют программе новых возможностей. Во время исполнения программы никаких шаблонов нет. Шаблоны позволяют меньше ручками по клавиатуре долбить.

Не соглашусь, тут не есть абстракция только ради абстракции.
Тут есть полиморфизм повыше обычного ООПшного, т.е. полиморфизм типов очень близкий к функциональному программированию, т.е. вот реализуй полиморфную для любых типов ф-цию swap?
В STL она есть, на любом функциональном языке или есть, или реализуется очень элементарно.
Покажи как это реализуется на обероне?

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

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

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

СГ>А Вы хоть знаете что такое оператор WITH? Или это Вы взяли with из того паскаля, который был сразу после Алгола?
Да-да тот самый маразм...
СГ>На всякий случай напишу что такое оператор WITH. В оберонах WITH — это оператор конкретизации типа.
А ну значит не все так плохо... хоть что-то понял...

СГ>Смысл: Если динамический тип полиморфной переменной x оказался T1, то выполняется S1 внутри которой x рассматривается как переменная типа T1; в противном случае если динамический тип полиморфной переменной x оказался T2, то выполняется S2 внутри которой x рассматривается как переменная типа T2; в противном случае выполняется S3.
И зачем ради этого вводить специальную конструкцию в язык? Это что так часто нужно? Вот в С++ есть dynamic_cast и его хватает на все случаи жизни. Да и нужен он очень редко. Ибо виртуальный функции рулят.
Вобще говоря знать динамический тип объекта нужно на столько редко что введение в язык конструкции которая позволяет проверить объект на принадлежность к нескольким типам заставляет задуматься очень не хорошими мыслями об авторе этого языка...

ЗЫ Ловкость рук и...

#define with(dest, src, type)if(type* dest = dynamic_cast<type*>(src))
void MyProc(base* p)
{
    with(x, p, T1)
        std::cout << x.Str << std::endl;
    else with(x, p, T2)
        std::cout << x.Value << std::endl;
    else 
        std::cout << "Че за хрень?" << std::endl;
}

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

СГ>Для написания программ общего назначения, разумеется.
Для этого достаточно машины Тьюринга.
СГ>Самый первый Оберон-1 можно рассматривать как кросплатформенный крос-архитектурный объектно ориентированный ассемблер на базе которого можно создавать новые расширения языка более удобные для той или иной предметной области.
Ну С++ для этих целей подходит по крайней мере не хуже. А если учесть шаблоны то обероны и рядом не валялись.

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

K_O>О, как вы неправы, создает и еще как! Для больших С++ проектов после появления IncrediBuilda это — самый больной вопрос. Линковка в течении 40 минут на современном компе — это далеко не фантастика. Более того, это один из главных тормозов в разработке сложных систем. Проверено на собственной шкуре.

Ну хорошо, давайте уточним, а что такое "большой проект"? Это сколько строк кода? И на какой машине делается сборка?

D>>Что же происходит в "модульных" языках? Да то же самое, совершенно то же самое. С той лишь разницей, что все имена (сигнатуры) в них разбиты на группы, которые относятся к разным модулям.

K_O>Нет, в модульных языках есть одно существенное отличие — информация о типах данного модуля содержится в скомпилированных объектных файлах. Эта информация доступна компилятору при компиляции другого модуля, который содержит секцию импорта из другого модуля. В результате — каждая строка в исходном тексте программы обрабатывается компилятором ровно один раз.
K_O>А теперь вопрос: сколько раз при компиляции большого С++ проекта компилятор обрабатывает, скажем, файл stdio.h?

Не пробовали использовать precompiled headers? Один раз. Всего один раз.

Кроме того, позвольте напомнить, в каком контексте прозвучало утверждение Сергея:

СГ>А еще тормоза компиляции происходят из-за того что в Си/Си++ можно влюбом месте программы написать:
СГ>

СГ>{
СГ>  extern void XerZnaetKakayaFunkciyaFigZnaetGdeOnaOpredelena();
СГ>  XerZnaetKakayaFunkciyaFigZnaetGdeOnaOpredelena();
СГ>}
СГ>

Что тут нужно искать в объектных файлах кроме сигнатуры функции? Зачем в этом случае информация о типах?