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


Конечность является формальным признаком алгоритма.
http://ru.wikipedia.org/wiki/Алгоритм
Так что это просто ошибка. :)

Может лучше алгоритм рассматривать как чётко определйнную последовательность действий,
а систему через логику взаимодействия элементов?

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

Другой вариант, даже более вероятный - не хотят использовать слишком высокоуровневое представление. Если по .NET-коду уже можно декомпилировать более-или менее читаемый исходник, то если ввести в представление еще больше семантики, то не станет ли это вообще как раз плюнуть? Для бизнес-технологий это ой как нехорошо. А для опенс-соурс - как раз даже наоборот :-)

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

Ответ на »сообщение 4318« (Антон Григорьев)
___________________________
>>>Вообще, с этими стандартными библиотеками возникает интересный вопрос.
Совершенно верно: компактность синтаксиса замечательная вещь (до определенного придела), а компактность словаря большая беда.
Но такова уж судьба авторских языков: компактный с единой идеей синтаксис и бедный словарь. Разработка стандартных библиотек работа не для одиночек. И толпой энтузиастов их не создать, требуется некоторый комитет с серьезными ресурсами. Или крупная фирма.

В отношении модульного программирования и его истоков есть довольно интересная информация.

В 1953-1954 гг. выдающий советский математик акад. Лев Витальевич Канторович (1912-1986), которому в 1975 г. была присуждена Нобелевская премия по экономике, высказал ряд идей, положивших начало крупноблочному программированию и т.н. деревьям Канторовича (внутреннее представление программы). Он ввел в рассмотрение составные данные как объект программы и определил понятие дескриптора ("маркер", определяющий способ доступа к компонентам динамического объекта). Предложил "геометрические операции" — правила композиции составных объектов из простых. Как отмечают А.П.Ершов и М.Р.Шура-Бура, "процесс выполнения программного комплекса, представляющего собой информационную сеть (схему) отдельных модулей, Л.В.Канторович рассматривал как функционирование некоторой сверхпрограммы, которая определяет выполнение модулей на основе анализа информационных и управляющих связей схемы. Многие положения крупноблочного программирования были позднее переоткрыты или заново осмыслены на более высоком уровне при разработке систем работы со структурными файлами и в том, что сейчас называют модульным программированием".

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

Ответ на »сообщение 4312« (Илья Ермаков)
___________________________
то я к тому, что обратная совместимость не является причиной неиспользования Сановцами деревьев Франца. Интересно почему тогда не используют?
Ответ на »сообщение 4314« (Mirage)
___________________________

Ответ на »сообщение 4312« (Илья Ермаков)
___________________________
Это я к тому, что обратная совместимость не является причиной неиспользования Сановцами деревьев Франца. Интересно почему тогда не используют?
Шут их знает... Много причин может быть.
Изначально, когда Яву делали, не рискнули использовать чрезмерно новаторские концепции, предпочли попроще, но чтобы работало... В дальнейшем про это могли и просто забыть, а Франц сам не напоминал ясное дело :-)

Другой вариант, даже более вероятный - не хотят использовать слишком высокоуровневое представление. Если по .NET-коду уже можно декомпилировать более-или менее читаемый исходник, то если ввести в представление еще больше семантики, то не станет ли это вообще как раз плюнуть? Для бизнес-технологий это ой как нехорошо. А для опенс-соурс - как раз даже наоборот :-)

Ответ на »сообщение 4318« (Антон Григорьев)
___________________________

В качестве достоинства Оберона нередко приводится то, что его полное описание занимает двадцать страниц против тысячи страниц описания C++.

С одной стороны, 16 страниц описания языка -- это достоинство. А с другой -- недостаток. Почему столь кратко Вирт излагает язык? Это отличительная черта европейской школы, традиций, которые были заложены Петером Науром. Описание Алгола-60 составляло именно 16 страниц. См. http://www.europrog.ru/book/alpn1963e.pdf

Что касается C++, то как Вы думаете, реально изложить этот язык со степенью детализации Вирта хотя бы на 30 стр.? В Обероне количество сущностей, средств и их комбинирования очень мало. Неудобство в том, что надо самому домысливать, какие возможности эта простота в себе таит. И это не всегда хорошо. Повышает барьер освоения. Требуется более высокая подготовка. Вот почему язык пока лучше осваивается с помощью носителей знаний и технологий, а не самостоятельно по описанию и книгам.

Чтобы въехать в Оберон, вообще говоря, нужно брать описание языка и изучать детально всю пятерку книг Вирта по Оберону -- это 65+442+338+179+131=1155 стр. Лучше брать Programming in Oberon и Compiler Construction. Многое будет понятно. Хотя то, что мы тут обсуждаем, Вы даже там не найдете. Нюансов немало. Простота обманчива.

Я уже отмечал, что Оберон в большей степени рассчитан на тех, кто готов самостоятельно разрабатывать (практически с нуля), а не комбинировать уже готовое. Это разная психология разработки.

Что касается библиотек -- да, это уязвимое место Оберонов. С ними наблюдается вполне объяснимая напряженка. Значит, есть над чем работать. Что же до их описания -- вряд ли разумно пытаться не глядя переводить на Оберон библиотеки других языков. Надо делать свои, проектируя их более компактно и продуманно, либо подключаясь к уже готовенькому.

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

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

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

Ассемблер и Оберон
В принципе -- да, но ассемблер - не 3GL, потому его упоминать не стал.

Это я не в рамках диспута с Вами
Это я в целях более корректного отражения идей ASU :-)

»сообщение 4272« (ASU)
Да, как видите, и ассемблер ему в этом ничуть не уступает... следовательно, и ассемблер обладает средствами разработки систем... :)

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

Нет, Франц в Sun вроде не работает - или уже работает? :-)

Вспоминается известный мультик: "Таити, Таити... Нас и тут неплохо кормят..." :) Он все там же, в Ирвайне, в Калифорнии. Он все гранты с американцев, с их Java заколачивает... Молодец, а чего это Европе раскошеливаться, когда можно за счет американцев? Его персональная страничка -- http://www.ics.uci.edu/~franz/

Там открыто публикует и финансовые детали по грантам. Впечатляет.

Маленькое экспресс-введение к подходу Франца тут: http://www.europrog.ru/qa141005.html

Ответ на »сообщение 4315« (Стэн)
___________________________

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

Это не совсем верное утверждение. Есть языки, в которые на уровне либо самого языка, либо СТАНДРТНЫХ библиотек встроены средства создания распределённых приложений. Java, например, или C#. Конечно, от зоопарка операционных систем это в полной мере не спасает, но если везде установлена подходящая среда исполнения, всё же можно говорить о том, что одни языки подходят для создания таких систем лучше, чем другие.

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

Вообще, с этими стандартными библиотеками возникает интересный вопрос. В качестве достоинства Оберона нередко приводится то, что его полное описание занимает двадцать страниц против тысячи страниц описания C++. Да, но при этом в описание C++ входят многие вещи (например, исключения), которые в Обероне предлагается вынести в библиотеки. Я уж молчу о том, что описание C++ включает в себя и описание STL. Следовательно, чтобы программист на Обероне реально имел все те же средства, что и в C++ (именно имел готовые средства, а не принципиальную возможность их написать), он должен использовать дополнительные библиотеки. Пердположим, что эти библиотеки уже есть (стандартные или нет - не суть важно). Но тогда программисту придётся изучить не только описание самого языка, но и документацию на эти библиотеки. Сколько страниц это будет? Далеко не 20.

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

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

А может уже используются?

Кто использует, особо об этом не трепется :) В диссертации Франца была важная оговорка -- его подход не заточен конкретно под Оберон. Можно применять и для других языков. В принципе это и так очевидно.

На EuroProg в новых поступлениях выложен ряд весьма интересных материалов, имеющих отношение к данной дискуссии. Там же есть и работы по JIT -- редкая работа Esmertec (они в свое время ее изъяли быстрехонько со своего сайта) -- коротенький такой ликбез по подходам компиляции: Way Ahead of Time compilation (WAT), Ahead of Time compilation (AOT), Just in Time compilation (JIT) и Dynamic Adaptive Compilation (DAC). Там же интересная работа Кистлера и Франца 2003 г. Из нее понятно, куда движутся их идеи.