Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  16:31[Войти] | [Зарегистрироваться]
Обсуждение темы:
Оберон-технология: особенности и перспективы


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 6256 сообщений

Добавить свое сообщение

Отслеживать это обсуждение

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 3356—3347 | 3346—3337 | 3336—3327 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 292


№ 3346   20-03-2007 04:37 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3340« (Eugene)
___________________________

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

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

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

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

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

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

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

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


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

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


№ 3345   20-03-2007 04:04 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3344« (Trurl)
___________________________

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

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


№ 3344   20-03-2007 02:09 Ответить на это сообщение Ответить на это сообщение с цитированием
>>>Короче, хотелось бы понять как именно реализовывать алгоритмы на самом чистом ФЯ.
Действительно, для многих задач не удается построить фунциональные алгоритмы такой же сложности, как классические императивные решения. С другой стороны, не доказано (пока?) что это невозможно.
Есть, правда, один трюк, когда императивноая программа маскируется под функциональную.


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


№ 3342   19-03-2007 15:39 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3341« (Geniepro)
___________________________

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

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


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


№ 3341   19-03-2007 15:19 Ответить на это сообщение Ответить на это сообщение с цитированием
У меня маленькая просьба к Илье Ермакову.

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


№ 3340   19-03-2007 14:24 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3267« (Руслан Богатырев)
___________________________

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

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

С уважением,


№ 3339   19-03-2007 14:24 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3338« (Руслан Богатырев)

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

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

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


№ 3338   19-03-2007 13:56 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3331« (slava)
___________________________

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

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

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


№ 3337   19-03-2007 13:50 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 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, так, как я уже сказал, меня это не волнует... пока.


<<<... | 3356—3347 | 3346—3337 | 3336—3327 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 292


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
Функция может не работать в некоторых версиях броузеров.

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования