OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 19 Октябрь, 2018 07:25

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 10 ] 
Автор Сообщение
 Заголовок сообщения: Оберон парадигма?
СообщениеДобавлено: Четверг, 04 Декабрь, 2014 17:06 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Объясните несведущему, что такое оберон парадигма?

Что это, не флейма ради, токмо для образования.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон парадигма?
СообщениеДобавлено: Четверг, 04 Декабрь, 2014 21:52 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9010
Откуда: Россия, Орёл
Что такое Оберон-парадигма?

Дам ответ в стиле "как лично я понимаю Оберон-парадигму и что она мне даёт".

Мой взгляд предыдущих лет я излагал в ряде статей: http://i.ermakov.pw/pubs.php (в частности. "Оберон-технологии: что это такое?" и "Некоторые идеи архитектуры Оберон-систем".

Попробую из текущего момента и основными мазками.

1. Что такое по своим качествам язык Оберон в ряду остальных?

Ф. В. Ткачёв когда-то показывал его место на плоскости из двух осей: быстродействие (=комплируемость) и гибкость (расширяемость).

Часть языков группируются вдоль первой оси, часть - вдоль второй (динамические языки) - и очень мало - в верхнем правом углу. Как пример проблемы - постоянная гибридизация пар языков, допустим, в игрострое или системных задачах, или "научке" - одного быстрого для ресурсоёмкой части (С++, например) и второго, удобного для скриптования и интерактивной работы (Python, Lua, Юникс-скрипты всяческие - тот Python, TCL/Tk, Shell). Оберон оказывается именно в этом углу. Спорный вопрос - кто там ещё и насколько сопоставим, но что таких немного - это понятно. Те же Java и C# сейчас обыгрывают Оберон по быстродействию только за счёт эффективных новых реализаций и отсутствия инвестиций в современные компиляторы Оберона. Обыгрывают с супер-сложными рантаймами, нивелирующими их языковые проблемы (типа только динамических структур и т.п.). Если же считать одной из составляющих гибкости-расширяемости не только рефлексию и динамическое связывание компонент - а ещё и общую простоту... Ведь что легче сопровождать и развивать, на протяжении двух-трёх десятков лет? И для написания сиюминутного "клея" что легче использовать (если человек берётся за программу раз в полгода - что ему легче вспомнить?)

Я бы выделил для выяснения места Оберона в ИТ-экосистеме другие 3 оси:

Простота - жёсткость - расширяемость.

Жёсткость - в смысле возможности создать статически проверяемый "каркас жёсткости" для программы. Как приятное следствие - возможность разрабатывать "почти готовое ПО" без обильного покрытия тестами каждого мелкого кубика.

Трудно найти много соседей Оберону в верхнем дальнем углу этих трёх осей.

Жёсткость - расширяемость: Ada, C#, Java, Haskell

Простота - жёсткость: ну, это скорее к языкам прошлого поколения (Modula-2, старый Pascal, нераздутый Fortran в некоторой мере, наверное...)

Простота-расширяемость: Лиспы всякие, Луа и прочие.

А всё вместе? Только что-то близкое, та же Modula-3. Может быть, нечто из компактного статически типизированного компилируемого функционального (OCaml какой-нибудь?).

Далее, недавно отвечал для себя на вопрос о различиях между той же Modula-3 и КП. Modula-3 нравится и на "оторванный от конкретики", чисто эстетический взгляд может смотреться более гармоничной. Однако что-то где-то лично меня напрягает. Как с теми же перечислимыми типами и проч.: вроде, для инженера и "эстетично, надёжно" и т.п. Но... Потом сформулировал своё ощущение: это уже попытка дать какие-то базовые вещи, полезные для предметных областей, для выражения семантики задачи. Но это скользкий путь - ибо задачи столь многообразны, что любые такие кубики быстро начинают жать (кому-то ещё и единицы измерения нужно контролировать - и чем больше зарываешься, тем более многообразия. Единицы измерения же контролировать можно уже с таким количеством нюансов, что не сделаешь заранее ничего, пригодного для широкого круга задач). Отсюда становимся на путь не определять в языке, а давать определять части языка динамически - и получаем взрыв безумия типа Nemerle и ко. Таким образом, имеет смысл вообще исключить из языка всё, сколь-нибудь ориентированное на прикладную специфику. А оставить языку 3 функции: 1) классно абстрагировать от физической машины, при этом оставляя полную прозрачность в отображении на императивный вычислитель; 2) давать "рёбра жёсткости" - средства статического контроля, позволяющие отсеять процентов 80 наиболее досаждающих ошибок, не гоняясь за каждой остальной мелочью, коих туча разных. Не нужно думать, что от контроля прикладной семантики мы отказываемся. Всегда есть возможность заложить уже свои рёбра жёсткости в фреймворках, чтобы уже защитить себя от каких-то нарушений прикладной семантики. 3) Давать средства расширения (полиморфизм и динамическое связывание), пригодных для безболезненного включения в систему компонентов, неизвестных на этапе её создания. Эти 3 функции в точности и оставлены в том же КП. При этом КП расширен над Обероном только по линии этих 3 функций, никаких "реверансов" в сторону прикладной семантики.


Последний раз редактировалось Илья Ермаков Четверг, 04 Декабрь, 2014 23:38, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон парадигма?
СообщениеДобавлено: Четверг, 04 Декабрь, 2014 21:56 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9010
Откуда: Россия, Орёл
2. Что такое операционные оболочки Оберона (ОС, BlackBox и др.)?

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

Опять же, простота и ориентация на "дать удочку для удобного решения сложных и нестандартных задач".

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон парадигма?
СообщениеДобавлено: Четверг, 04 Декабрь, 2014 22:11 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9010
Откуда: Россия, Орёл
3. В плане культуры мышления.

Ну, кое-что там было у нас постоянно разжёвано аж с 2005-го года... И даже уже подзабылось, как само собой разумеющееся для сообщества :)

Пара составляющих:

1) Культ "гарантоспособности" (как выражается Влад Жаринов) - т.е. использования таких приёмов программирования и мышления при программировании, которые ведут к возможности по-максимуму отвечать за свойства продукта. Кстати, это не обязательно давать совсем уж 99,999999 надёжный продукт - там всё же не обойтись без спец. методов, доп. фазы тестирования и проч. Но внутри класса высококачественного ПО можно таки выделить свою градацию - вот умение попадать на тот уровень гарантий, который уместен по задаче.

Самый нижний уровень - на систему уверенно можно положиться. При возникновении остаточных проблем (которые не убраны, допустим, ввиду не проводившегося серьёзного тестирования) за счёт хорошей структуры ПО и контрактно-ориентированного программирования они устраняются разработчиком моментально. Частота проблем падает экспоненциально.Т.е. на этап эксплуатации выходит система "ПО + оперативная поддержка разработчика", она начинает работать уверенно, и через определённое небольшое время система уже работает безотказно.

2) Стремление любую задачу отрабатывать "по 2-му умотипу" (http://www.inr.ac.ru/~info21/princypKalashnikova.htm). Т.е. не остановиться влюблённо на первом решении ("Как выс...но, так и заморожено" (С) Лесков) - и уже тем более не спешить подсаживать мир на это первое решение, а сделать несколько итераций очищающего и упрощающего редизайна. Любимое оправдание "для сложных проблем - сложные решения", но практика убедительно показывает, что большинство предлагаемых решений - избыточно сложны (часто многократно) для своих проблем. Именно в силу того, что никогда не подвергались ни одной итерации очищения и упрощения. Только обратный рост. Индустрия предоставила в последнее время 2 примера, что десятилетия мы жили в усложнённом тупике в двух областях: в параллелизме и в СУБД. Подробнее вот здесь я высказывался на эти две темы: http://www.inr.ac.ru/~info21/zametki/welcome.html Сегодня добавилось свежих примеров: подход Д. Дагаева с его ПО для АЭС на Обероне и кооперативной многозадачности; переход A2 и Active Oberon на оную.

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

Отсюда так и просится понятие "информационная экология", "экология программирования" - как борьба с тотальной загрязнённостью мусором информационной среды, ИТ и программных технологий.

Ещё на эту тему хорошо почитать концептуальный текст Информатики-21: "Математика + информатика + языки", там всё классно по полочкам разложено http://www.inr.ac.ru/~info21/MIL/welcome.html


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон парадигма?
СообщениеДобавлено: Четверг, 04 Декабрь, 2014 22:18 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9010
Откуда: Россия, Орёл
4. В плане "личного инструмента в арсенале"

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

Кстати, повально наблюдается феномен: стоит человеку чуть приподняться над уровнем технических задач, начать руководить, или выстраивать бизнес, как он выпадает с острия технических проблем, просто не в силах быть компетентным в том потоке фекалий, который там бурлит. ИТ-менеджеры тут же вынужденно теряют интерес ко всем технологическим деталям, оправдываясь "при должной организации процесса дом можно построить даже из кизяка", и т.п. Очень ценна возможность содержательно работать даже при нехватке времени.

Так что лично я благодарен и Оберон-парадигме, и идеям проекта "Информатика-21" за вот эту возможность, которой пользовался 10 лет с 2005-го года. Хотя сейчас и настал момент углубиться обратно в содержательную работу, чтобы воплотить накопившиеся замыслы и заготовки.

Кстати, пример на "2-й умотип" даже внутри Оберон-технологий: многократно спрашивали, а почему был остановлен успешно реализованный "клон" в ББ Active Oberon-а (Active BlackBox). Просто потому, что интуиция, под влиянием "прессинга" принципов, сформулированных координатором "Информатики-21", подсказала, что это - не доработанная концептуально модель, тупиковая. А то ведь мог бы и несколько лет поддерживать, тратя время и силы... Вместо этого силы тратились на альтернативную модель. Пусть она окончательно отлилась только недавно - ну так как раз сейчас и у прообраза Active BlackBox-а произошел прыжок на альтернативные рельсы :) К вопросу о том, что чем бежать догонять, иногда полезнее остановиться и хорошенько подумать. Даже если думание будет продолжаться не один год.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон парадигма?
СообщениеДобавлено: Пятница, 05 Декабрь, 2014 10:26 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Илья Ермаков писал(а):
Сегодня добавилось свежих примеров: подход Д. Дагаева с его ПО для АЭС на Обероне и кооперативной многозадачности; переход A2 и Active Oberon на оную.


Ого. Подписываюсь, очень интересно узнать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон парадигма?
СообщениеДобавлено: Пятница, 05 Декабрь, 2014 10:28 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Спасибо Илья, за такой полный ответ. Очень много мыслей появилось, нужно время для переваривания, так сразу ответить не смогу.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон парадигма?
СообщениеДобавлено: Пятница, 05 Декабрь, 2014 12:13 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 505
Jordan писал(а):
Илья Ермаков писал(а):
Сегодня добавилось свежих примеров: подход Д. Дагаева с его ПО для АЭС на Обероне и кооперативной многозадачности; переход A2 и Active Oberon на оную.


Ого. Подписываюсь, очень интересно узнать.

Оно никуда не перешло, А2 остается многопоточной, просто есть альтернативная ветвь развития с неясными перспективами. Возможно, что ветки сольются, но будет выбор модели при сборке, тем более, что приложения переписывать нет необходимости.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон парадигма?
СообщениеДобавлено: Пятница, 05 Декабрь, 2014 12:36 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9010
Откуда: Россия, Орёл
Jordan писал(а):
Ого. Подписываюсь, очень интересно узнать.


Так всё это тут же рядом обсуждается уже месяц :)
"Сегодня" - это я имел в виду вообще текущий момент.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 08 Январь, 2015 08:45 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Илья Ермаков в viewtopic.php?p=89901#p89901 писал(а):
...
1) Культ "гарантоспособности" (как выражается Влад Жаринов) - т.е. использования таких приёмов программирования и мышления при программировании, которые ведут к возможности по-максимуму отвечать за свойства продукта.
...

Ну, я-то предпочитаю термин "полная ответственность"... даже указывал на это... а, вот в Разд.2 второй статьи отсюда где-то. Ну а "гарантоспособность", как где-то у автора силуэтного техноязыка, происходит с родины термина "информатика" и вертолётоносцев "Мистраль"... :) Но это так, лирика... тем более, что определение в общем такое же...

А вот вводимые метрики Оберонов напоминают о системном описании предметик в общем случае заранее не определённых. Что связывается с источниками отсюда. Ну, тут цитату уместно привести (курсив автора рецензии; см. и год публикации):
Клименко С.В. в МПСиС. - 1989. - №3. - с. 21..22 писал(а):
... сам по себе перенос не гарантирует получения полностью совместимой операционной среды. Более того, подход вообще ничего гарантировать не может. Т.о., основная идея письма И.Я. Ландау <тоже входит в публикацию МПСиС, с.20..21 - В.Ж.> - аккуратный перенос одной версии на все машины как панацея - технологически ошибочна. Можно также показать, что она бесплодна и в стратегическом плане, отметив неизбежность различий и фундаментальную причину их возникновения - развитие системы.
... Между тем,
Г.С. Цейтин в частной переписке писал(а):
переносимость средств, разрабатываемых в системе типа Unix, основывается не на жёстко аксиоматизированной модели виртуальной машины, правильная работа которой гарантируется лишь в случае её точной реализации ..., а, совсем напротив, на свободном сочетании и взаимодействии машинно-зависимых и машинно-независимых средств, при котором заранее неизвестно, что при переходе в новое окружение сохранится, а что заменится. Переносимость обеспечивается не тем, что система отгораживается от изменений в окружении, а тем, что она хорошо расчленена на элементы, и изменения затрагивают лишь немногие из них.
Т.о., с нашей т. зр., более правильным путём, в противоположность ... отгораживанию от развивающегося мира, является выработка и программная поддержка ориентированной на развитие и изменение окружения методологии мобильного программирования, ...
Машинная независимость и переносимость - различные понятия. ОС Unix является переносимой, но машинно-зависимой. В свете настоящего соображения мы рискнём посоветовать т. Ландау, по возможности, избегать гладких переходов от "не вполне совместимы" к "совместимости не будет" <при чтении места с этими "переходами" сложилось впечатление, что пример и "неотвязки смыслов от словоформ"... а отвязать постарался Клименко, прежде всего как раз вводя различение понятий - В.Ж.>.
Кстати, адаптация ... да и разработка программного продукта вообще), должна требовать квалификации, и весьма высокой, в зависимости от целей.
Наконец, имеет смысл повторить - недопустимо отрывать перенос ядра от переноса системы в целом. ...
- отсюда вопросы.

1. Вот парадигма, как она сформулирована, предполагает поддержку такого хорошего структурирования? и не намечают ли Клименко и Цейтин основания именно системного описания? не туда ли движутся и Обероны как часть языкового базиса?
    Как пример - модуль SYSTEM, наверное, можно рассматривать и как следование путём не "жёсткой аксиоматизации виртуальной машины", но "вычленения элементов, которые должны измениться при переходе в новое окружение".

2. В предлагаемом метрическом пространстве языки исходного текста для этой поддержки и должны "группироваться", как Илья говорил тут?.. или как?

3. А какие требования можно сформулировать к языкам документирования, т.е. уже "текста как интерфейса" (в основе, со включением таблиц/изображений уместным, разумеется)? и как они отражаются в предлагаемой метрике (может, для этого ещё что-то надо мерить)?
    ТКИ, по идее, нужно оценивать как поддержку хорошего структурирования для "носителя языка описания машин языка"?

Я это к чему ещё - когда-то обсуждали, "как измерить Оберон". Но уже Мейер, допустим, говорил, что для корректной "арифметизации" синтаксиса, например, способ формально-грамматического описания д.б. одинаков для всех обсчитываемых знаковых систем (ЯП в частности). В уже упомянутой статье было об этом в п. 3.1, но в первоисточнике поконкретнее (на с. 305..306, в выдержку не вошли).
А ведь мерить надо и часть описания, "машине языка" не предназначенную (вот хотя бы аспект: "Гораздо интереснее была бы публикация научно подтверждённой информации о том, понимание проблем какого уровня сложности поддерживает грамматика каждой модели." у Блинова). Как с этой задачей (может, Илья и над ней работал)?.. Интересны мысли по её решению (и что сформулированная парадигма может дать для этого)...


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 10 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB