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

Руслан, упоминание Native Oberon как распределенного проекта (проекта над которым работает распределенная группа программистов, которые географически удалены друг от друга) по моему ошибка.

Я не утверждал, что Native Oberon -- распределенный open source project. Если Вы помните, в ответ на Вашу реплику (»сообщение 14«) я ответил, что "нет никаких проблем в реализации такого проекта", поскольку XDS работает на основе исходников в текстовом представлении (»сообщение 15«). После чего появилось утверждение в безапелляционной форме от г-на 1 (»сообщение 16«) -- "проблем в реализации такого проекта может быть и нет, но проекта тоже нет (ни одного)". Я дал ссылку на Native Oberon в SourceForge и спросил -- а какой статус носит этот проект (»сообщение 17«). На что услышал -- "это не проект" (»сообщение 26«). Моя попытка уточнить критерии open source project в понимании все того же г-на и то, почему вдруг Native Oberon будучи "не проектом" оказался в SF вызвала буру негодования г-на 1 с приведением доказательств мертвости проекта.

Обратите внимание, как происходит подмена понятий: Native Oberon (как, кстати и практически все работы по проекту Oberon и его последующему развитию) являются не просто OpenSource-проектами, но и проектами с открытой документацией. Это прекрасно известно любому, кто мало-мальски изучал мир Оберонов. Был проект или сейчас ведется -- эта тема вообще не обсуждалась. Таким образом, проект Native Oberon был назван даже не просто мертвым проектом (имелось видимо в виду то, что он уже не развивается), но вообще не проектом. Думаю, тут даже нечего комментировать. Точно также можно считать, что и проект Oberon -- это тоже не проект. И вообще непонятно, что в этой ветке обсуждается. Приехали.

Что касается того, почему исчезающе мало проектов на Обероне (причем не только с открытыми исходниками), почему Оберон не в "фаворе" -- эту тему неоднократно комментировал и раскрывал. Остались вопросы? Так задавайте прямо, чего ходить вокруг да около?

Может быть в некоторых случаях неудобство а в некоторых невозможность работы с CVS играет не главную роль в этом.

Нет такой невозможности, если человек работает с XDS. А если он зациклен на BlackBox (или ETH Oberon), то, пардон, это уже не ко мне. Если оппонент не понимает, зачем нужны сторонние общепризнанные средства контроля версий, это говорит только о том, что он либо никогда не работал в индустрии ПО, либо просто считает, что всех должна устраивать доморощенность безальтернативного инструментария там, где можно и нужно применить стандарты де-факто, на которых работает весь мир. Причем достигается это всего лишь поддержкой текстового представления как базового (а не временной выгрузкой бинарника в текст). В результате получается просто бессмысленный, никому не нужный диспут, напоминающий разговор слепого с глухим.

По поводу приоритетов, заимствований и пр.
Кто-нибудь обращал внимание на эту цитату?


Good composers don’t imitate, they steal.
Igor Stravinsky


www.zonnon.ethz.ch/archive/The_Concepts_of_Zonnon_6_y041123.pdf

а как обстоят дела с распределением задач под многоядерные процессоры в бутылке и зонноне соответсвенно?

Руслан, упоминание Native Oberon как распределенного проекта (проекта над которым работает распределенная группа программистов, которые географически удалены друг от друга) по моему ошибка.
Да проект зарегестрирован на SF. Но над ним никто не работает и никогда не работал на SF.
Более того я поискал на SF. Там всего 4 проекта на обероне, все мертвые, т.е. не развивающиеся.
Что лишь подтверждает что на обероне ПРАКТИЧЕСКИ не пишется распределенных проектов.
Может быть в некоторых случаях неудобство а в некоторых невозможность работы с CVS играет не главную роль в этом. Спорить не буду. Может оберонщики такой странный народ, который предпочитает работать в одиночку.
Это уж вам решать. :))

Ответ на »сообщение 41« (Руслан Богатырев)
___________________________
Еще раз пожалуйста, как Вы сохраните состояние системы Oberon System 3 между сеансами (какой командой)?

Какие могут быть внешние средства контроля версий в ETH Oberon, если ETH Oberon - stand-alone, то есть по отношению к ней нет внешней системы?

Чем плохи перечисленные мной имеющиеся в ETH Oberon средства контроля версий?

Т, что Вы повторили мои слова Blackbox и других компиляторах уже прогресс.

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

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

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

Что позволяет сохранять: persistent-компоненты (гаджеты, команда Store), состояние системы Oberon между сеансами (в Oberon System 3).

Далее, ни ETH Oberon, ни BlackBox, насколько мне известно (и по моему мнению), в виду использования системой программирования исходных текстов в бинарном формате (вне зависимости от наличия механизма загрузки-выгрузки исходных текстов в текстовый файл) не имеют возможности использовать внешние известные (а не собственные) средства контроля версий. Средства, применимые для других систем программирования, средства, для которых работа с текстовым представлением -- основное требование.

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

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

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

Важное замечание, на этот аспект особое внимание обращал Вирт в статье "From Modula to Oberon". Но, на мой взгляд, это тема другой ветки. Это не Оберон-технология, а средство языка программирования. Хотя границу, конечно, проводить непросто.

Ответ на »сообщение 32« (Alexey Veselovsky)
___________________________
Речь шла о разнице между фактом и предположением. Когда пишется "Оберон системы ...", а на самом деле этого нет, то подобный пост естественно вызывает желание восстановить истину. Когда же пишется "по моему мнению "Оберон системы ..ю" то, зная что это не так, просто пожимаешь плечами и считая это личной реальностью автора.

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

Ну, стандарт Паскаля полноценным не назовешь.
Стандарт Модулы-2, по Вашей оценке, запутан и злоупотребляет формальной нотацией. А стандарта Оберона нет.

В принципе в оценке стандартов виртовских языков готов согласиться. Но есть ли международный стандарт язка Delphi, языка Java? Или они ликвидируют оный недостаток своей "массой"?

Ответ на »сообщение 30« (1)
___________________________
Извините, это был ответ на #28