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

Поскольку обсуждение проблем образования - offtopic,

Не уверен, что совсем уж offtopic. Эта ветка посвящена не только особенностям, но и перспективам Оберон-технологий.

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

Что касается перспектив Оберонов, то они складываются из известной тройки: образование-наука-индустрия.

Начну с конца, с индустрии. Место Оберонов здесь в настоящее время ограничено кустарным производством. В крупных компаниях (от 1000 человек), связанных с производством ПО, насколько мне известно, Обероны не используются. Это и понятно: там господствует мэйнстрим, в который Оберон не входит. Не уверен, что это плохо. Даже, наоборот. Оберон IMHO является конкурентным преимуществом в наукоемком ПО, разработка которого сосредоточена преимущественно в компаниях малого размера и в среде индивидуалов/фрилансеров.

Использование Оберонов в научной сфере идет в двух направлениях: как объекта исследований (преимущественно в теоретическом и системном программировании) и как инструмента исследований (прежде всего, в прикладном программировании). В качестве объекта исследований его изюминка состоит в том, что это крайне компактный полигон, квинтэссенция императивного программирования с выверенным синтаксисом и тщательно сбалансированным набором сущностей и средств для алгоритмического программирования (в контексте computer science) и для инфраструктурной обвязки (в контексте software engineering). Именно здесь в силу минимизации конструкций практически идеальное место для применения формальных методов (доказательное программирование), содействующих повышению надежности ПО. Инварианты, конечные автоматы, сети Петри и другие подобные формализмы в этой среде находятся практически в идеальных условиях. При этом не следует упускать из вида смежные парадигмы, которые не имеют прямого отображения в Оберонах. Речь, прежде всего, о функциональном и логическом программировании (включая constraint programming). Это важная основа для продуктивного использования Оберонов в индустрии.

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

Вот почему я полагаю, что широкое обсуждение вопросов образования в контексте Оберонов (если в качестве отправной точки брать "Потерянную дорогу" Вирта) в данной ветке форума более чем допустимо. Именно в этом смысле и поднимаю вопросы чемпионата ACM и спортивного программирования. Но пока нет критической массы, выделять отдельную ветку IMHO не стоит.


В общем, выполнять прогнозы Ивана Ильина и экспертов Horasis будет просто некому.

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

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

>>>Есть, правда, один трюк, когда императивноая программа маскируется под функциональную.

О чем речь?
Если не секрет, конечно. :)

>>>Короче, хотелось бы понять как именно реализовывать алгоритмы на самом чистом ФЯ.
Действительно, для многих задач не удается построить фунциональные алгоритмы такой же сложности, как классические императивные решения. С другой стороны, не доказано (пока?) что это невозможно.
Есть, правда, один трюк, когда императивноая программа маскируется под функциональную.

Ответ на »сообщение 3341« (Geniepro)
___________________________
Эти модули - в школьной версии от Инофрматики-21.
Скачать можно в Дистрибутивах на OberonCore и на www.inr.ac.ru/~info21.

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

У меня маленькая просьба к Илье Ермакову.

Илья, не могли бы Вы дать ссылку, где можно скачать эти нестандартные модули Info21olimpIn и Info21olimpOut, а то я всё никак их не найду и не скомпилирую Вашу программу. Мне любопытна её реальная скорость...

Насколько я понимаю, речь идет о подсистеме Info21.
Ее можно найти в Component Pascal Collection:
http://www.zinnamturm.de/DownloadsIN.htm#Info21
Другой путь.
Кажется, на орловском сайте лежит школьная версия ББ.
Там эта подсистема точно есть.

У меня маленькая просьба к Илье Ермакову.

Илья, не могли бы Вы дать ссылку, где можно скачать эти нестандартные модули Info21olimpIn и Info21olimpOut, а то я всё никак их не найду и не скомпилирую Вашу программу. Мне любопытна её реальная скорость...
Я пропустил через свою программу файл объёмом 107 мегабайт (9,5 млн строк, те 4 строки из примера в зацикленном виде), программа отработала за время, меньшее 10 мин, т.е. со скоростью 16 100 строк в сек. Хотелось бы сравнить со скоростью Вашей программы. Да, кстати, за время работы моей программы объём занимаемой ею памяти держался около 2.5-3 мегабайт... При этом программа постоянно считывала входной файл, а результаты были перенаправленны с экрана в другой файл, так что основным тормозом тут, вероятно, были дисковые операции...

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

Доброго времени суток!
Поскольку обсуждение проблем образования - offtopic, прошу заглянуть в »сообщение 160 в теме №345 на БП«

В общем, выполнять прогнозы Ивана Ильина и экспертов Horasis будет просто некому.

С уважением,

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

Бывает нужно всякие динамические структурки понасоздавать. Деревья всякие. Другой пример задачи на перебор. Перебираешь чего-то, отсекаешь решения, но держать все варианты где-то надо. А это некое дерево или несколько списоков. Можно конечно и не "подметать", но... во первых - так не хорошо :), а во вторых - утечка памяти все таки может аукнутся. Теперь представь, когда на вход даётся не один тест, а группа из 10-20 тестов. Если не подметать, то 20-ый может и не пройти. Например по времени из-за раздутой виртуальной памяти.

Опять же, если нет сборщика мусора, то не проблема и самому "подчистить", ведь структуры, не очень сложные. Меж-модульного взаимодействия нет :). Но на олимпиаде, каждая секунда дорога. Так что сборщик мусора лишним точно не будет.

Но вообще-то я уже лет 7 как не участвовал в олимпиадах, так что может сейчас сборщик мусора уже и не нужен...

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

Автоматическая сборка мусора.

А она-то зачем нужна в олимпиадных задачах? У меня сложилось ощущение, что на автоматическую сборку программисты подсели как на иглу.

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

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

Вас дезинформировали :)) Прежде всего скорость того или иного алгоритма зависит не от того функциональный или императивный язык, а от того статический он или динамический.

Эээ... кажется теперь вы меня не поняли... Как раз таки меня не интересует, что запрятано в О(), только асимптотика. А значит для меня: интерпретатор = компилятор. Т.е. если на неком интерпретаторе Оберона можно реализовать сортировку работающею за О(N log N), для меня это достаточно хорошо.

Не замечая константы перед N log N, я уравниваю динамичность и статичность. То что для меня действительно важно - это не ограничивает ли ФЯ инструменты для построения элементарных алгоритмов. Совершенно очевидно, что можно взять любой ИЯ, даже интерпретируемый, и фактически реализовать, например QuickSort без потери асимптотики ( О(N log N) ). Могу ли я сделать тоже самое на ФЯ ? Ладно, я согласен лишний раз побегать по списку, но не выйти из асимптотики, иначе это будет уже не Quick? И если - да, могу, то насколько изменится моя реализация от оригинальной? А также насколько легко тоже самое можно сделать с другими алгоритмами, например с HeapSort ?

Я боюсь, что многие реализации элементарных алгоритмов на ФЯ, является далеко не элементарными. И к сожалению дело не в динамичности...

Серьёзно, ну что это за вопрос "можно ли". Отвечаю - можно. Вам стало легче? Вы узнали из этого ответа КАК и ПОЧЕМУ?

Так вы уверены, что можете? например HeapSort? в студию!

ок, ваше замечание принято, надеюсь, что я объяснил свой вопрос в этом посте. Но на самом деле "Как?" и "Почему?", меня не сильно волнует, я вам верю, только пожалуйста без использования библиотечных функций, императивных свойств, ассемблерных/С-ишных вставок и без замен HeapSort на MergeSort. А в основном вы совершенно правы.

На счёт проблем с памятью. Как мне кажется это не настолько большая катастрофа, да чего то там выделятся, но это действительно зависит от реализации компилятора/Run-Time'а. А как я сказал меня волнует именно сам ФЯ. Короче, трудно доказать, что нельзя написать компилятор, который бы оптимизировал на все 100% работу с памятью.

Да и вообще, возможно стоит ввести для ФЯ другое определение используемой памяти. Например не количество всех NEW + все статические массивы + стэк, а максимальное мгновенное использование памяти. Что то вроде Work Set. А то что в некой сортировке, реализованной на ФЯ будет 100*N*log(N) раз вызываться NEW и DISPOSE, так, как я уже сказал, меня это не волнует... пока.