Ответ на »сообщение 2584« (Руслан Богатырев)
___________________________

Еще один интересный момент. Как Вы думаете, в чем разница между языком программирования и алгоритмическим языком? Между этими терминами давно уже ставят знак равенства, а на самом деле разница-то есть. Более того, эта разница порождает и расхождение между европейской и американской культурами (школами) программирования.

Если немного углубиться в историю, годков так на 50, то можно будет обнаружить, что поворотным пунктом, где пути-дорожки Старого и Нового Света в отношении языков программирования разошлись, восходит к процессу создания и внедрения Алгола-60, а уж мытарства с формированием спецификации Алгола-68 только эту пропасть увеличили.

Датчанин Питер Наур в своих воспоминаниях о том периоде ("History of Programming Languages. The European Side of the Last Phase of the Development Algol 60", можно найти на europrog.ru) привел цитату из работы Хайнца Рутисхаузера, профессора математики в ETH Zurich, отца-основателя швейцарской школы программирования. Вот что писал Рутисхаузер (1967): "The situation was quite different in the USA, where an assembly language epoch preceded the introduction of algorithmic languages. To some extent this may have diverted attention and energy from the latter, but on the other hand it helped to make automatic programming popular in the USA. Thus, when in 1954 Laning und Zierler (Adams and Laning, 1954) presented their algorithmic language - the first one ever actually used - and shortly thereafter the IBM FORTRAN System (IBM, 1954) was announced, the scientific world was prepared for this new concept."

В Америке движение к ЯВУ (языкам программирования высокого уровня) шло снизу вверх, от ассемблера. А в Европе пошло сверху вниз (от человека, точнее, от формулировки и решения задач вычислительной математики). В общем-то, разница в восприятии и природе терминов computing science (Европа) и computer science (Америка), о которой писал Дейкстра в своих заметках, это лишний раз подчеркивает. Позднее Америка (как и почему - это предмет отдельного рассмотрения) навязала всем свою "геоцентрическую" модель мира.

Так вот. Оберон, хоть и язык системного программирования, но при этом является алгоритмическим языком. Си просто пытаются использовать в этом неподходящем для него качестве. Для Си процесс синтеза текста и машинного кода много проще процесса анализа (текста и кода). В Обероне же это сбалансировано.

Ответ на »сообщение 2584« (Руслан Богатырев)
___________________________
и все таки
разве Си не сложнее Оберона с точки зрения количества исключений из правил?
если он всем хорош для системного программирования то почему создалеи юникса и план9, ось инферно писали уже не на нем?

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

т.е. Оберон сложен так же как и Си...бр

Ожидаемая реплика. Типичный ложный стереотип.

Язык Си - простой язык:
1. С точки зрения грамматики языка
2. С точки зрения разработки компилятора и генерации машинного кода
3. С точки зрения быстроты освоения программистом

Сравнение сложности синтаксиса языка см., например, http://www.uni-vologda.ac.ru/cs/syntax/ariphm.htm

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

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

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

Ответ на »сообщение 2567« (Руслан Богатырев)
___________________________


Возьмем за отправную точку классический Оберон (уровень сложности - Си).

т.е. Оберон сложен так же как и Си...бр

Ответ на »сообщение 2574« (Руслан Богатырев)
___________________________

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

>>Понимаю, что вопрос трудный.
Но не могли бы Вы немного подробнее на него ответить?

Постараюсь это сделать в ближайшие дни.

Спасибо, буду ждать.

Ответ на »сообщение 2490« (Jack Of Shadows)

Если вас интересуют ДЕШЕВЫЕ распределенные базы данных, работающие на кластерах, то советую изучить архитектуру JavaSpaces (java) или Mnesia (Erlang) кстати БЕСПЛАТНЫЕ - это в отличие от вашего несуществующего Store - который еще написать надо (что бабушка надвое сказала) и в сроки уложиться, и в бюджет. И баги отловить, и обкатать, и с проблемами производительности столкнуться и их еще решить.

Базы данных меня не интересуют, они вообще здесь не причём. Задача чисто вычислительная. Жёсткие диски должны использоваться лишь потому, что оперативной памяти не достаточно. После того как вычисление закончено, вся информация с использованных дисков конечно будет стёрта.

Сами же CDR-ы хранятся где-то в БД билинговой системы, вычислительной программе до неё нет никакого дела.

Повторюсь: организовать обсуждаемое здесь специфическое вычисление над всеми CDR-ами средствами самой БД в которой они хранятся - возможно (так оно сейчас и делается на суперкомпьютерах HP), но это требует наличия суперкомпьютеров и ПО для них, что в совокупности стоит ~ $10'000'000.

Ответ на »сообщение 2579« (Alexey Veselovsky)
___________________________

Не знаю что это за кросскомпиляция такая, но вот в GCC промежуточным языком является нечто ассемблеро-подобное. Фронтенды Си, С++, Ада и прочие, выдают текст именно на этом вот языке.

Имеется в виду довольно обычная практика: программа на некоем ЯВУ компилируется в программу на Си, а компиляторы на Си есть для большинства процессоров.
Для промежуточного представления в GCC используется RTL (Register Transfer Language), близкий к ФЯ, но в данном случае речь идет не о нем.

Ответ на »сообщение 2573« (Руслан Богатырев)
___________________________
> Си занял уникальное место стандарта де-факто в качестве
> промежуточного языка для кросс-компиляции и работе на
> разных платформах во многом благодаря своей близости
> "золотой середине".

Не знаю что это за кросскомпиляция такая, но вот в GCC промежуточным языком является нечто ассемблеро-подобное. Фронтенды Си, С++, Ада и прочие, выдают текст именно на этом вот языке.

Ответ на »сообщение 2577« (Alexey Veselovsky)
___________________________

Оберон-2 это не ObjC, это скорее "Си с классами" - предтеча современного С++.

Why not? Можно и "C with Classes". Другое дело, что Objective C -- вполне конкретный самостоятельный язык, а "C with Classes" примерно тоже, что урезанная Modula-2 периода 1985-1986 гг. для реализации системы Oberon. Промежуточный язык. И трудно сказать, где заканчивается "C with Classes" (переименованный в C84, а технически менявшийся непрерывно в период 1979-1984), а где начинается C++. Хотя как аналогия - вполне.

Ответ на »сообщение 2576« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2566« (Илья Ермаков)
___________________________

Для Оберонов необходим единый стандарт на библиотеку метапрограммирования - это станет основой для любого взаимодействия, в том числе распределенного.

Еще один штрих. Семейство Оберонов достаточно разнообразно, но при этом "покрывает" большой пласт императивного программирования, что повышает ценность всего комплекса этих языков. Если выставить некие ориентиры, то получится что-то вроде
* Оберон - Си
* Оберон-2 - Objective С
* Компонентный Паскаль - Java
* Active Oberon - Limbo
* Zonnon - Modula-3 (с прицелом на .NET).


Оберон-2 это не ObjC, это скорее "Си с классами" - предтеча современного С++.