Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 5406 07-10-2007 10:41 | |
Ответ на »сообщение 5404« (Как слышно? Приём!)
___________________________
Как может асинхронное программирование при сети связей выиграть борьбу со сложностью?
Кто сказал, что в этой борьбе можно выиграть? :)
Тезис довольно простой: мы в значительной мере создаем себе сложности сами. Почему? Потому что так проще. :) И выгоднее.
Сложности современного программирования являются во многом следствием полувековой эволюции и многометрового наслоения адекватных и неадекватных вещей. В ходе этой эволюции выработаны свои защитые механизмы -- стереотипы. Они помогают быстро определиться с ответом (с принятием решения). Но при этом их базис и вся совокупность содействуют сложности, а не предотвращают ее. Сложность -- это гарантия зависимости потребителя.
Сложные вещи делать проще. Простые -- сложнее. Написать статью по нетривиальной проблеме на половину журнальной полосы много сложнее, нежели статью на несколько полос.
Асинхронное программирование -- лишь одно из звеньев цепи. Правда, очень важное. Это несколько иной подход к мышлению, к решению задач, к реализации проектов. Подход, в котором вместо "раньше - позже" преимущественно фигурируют причинно-следственные связи. Он не отвергает синхрон, просто становится над ним, становится первичным.
Асинхронное программирование лежит в русле идей В.Е.Котова, в русле работ по проекту МАРС середины 1980-х. Увы, в том проекте большей частью вынуждены были ограничиваться демонстрацией, "военным парадом" тех заделов, которые были созданы в предшествующие годы.
Асинхронное программирование может пронизывать все ведущие парадигмы (включая и ИП), ибо оно особенно важно на архитектурном уровне, при высокоуровневой композиции сущностей. Асинхронное программирование не только создает практически идеальную основу для автоматического распараллеливания, но и позволяет задействовать математический фундамент для ключевых, а не просто второстепенных вещей.
№ 5405 07-10-2007 10:01 | |
Ответ на »сообщение 5403« (Руслан Богатырев)
___________________________
Ответ на »сообщение 5402« (AVC)
___________________________
>>>Ну а если говорить о моём видении стратегии борьбы со сложностью, то, думаю, её вполне можно озвучивать уже сейчас. Это асинхронное программирование.
Асинхронное -- в каком смысле? (Вопрос задан в свете »сообщение 5387«.)
№ 5404 07-10-2007 09:59 | |
>>> Борьба со сложностью в рамках индивидуального программирования (и небольших проектов)
>>> вполне может решаться подходом языков-ядер (Оберона, Лиспа, Пролога и др.).
>>> Минимализм и концептуальная экономия.
>>> Но как только речь идет о других масштабах и другом процессе разработки
>>> (коллективном, индустриальном), требуется предпринимать дополнительные шаги
А не путается ли тут сложность проекта (объективная) и сложность пастьбы котов (субъективная)?
Очень опасная путаница. Задумывался UML как средство создания сложных моделей.
Затем превратился в средство контроля за разработкой. Именно это и погубило UML.
С одной стороны (со стороны разработчиков и Ко) - увлечение конечными автоматами и изобретением
очередного языка и компилятора было супротив интереса к нотации больших систем.
"Минимализм и концептуальная экономия", "сложные проблемы имеют простые решения".
С другой стороны - удобство и наглядность графического представления (по аналогии с презантациями)
были мгновенно впитаны менеджерами проектов. И UML стал игрушкой офисного планктона, а жаль.
Нужен надязык, но уже не UML. Там всё обросло ракушками администрирования.
Смотреть надо в сторону сетей Петри и чего-то более неформального и нечёткого.
Сложность это не хорошо и не плохо. Это параметр, это степень детализации.
Надо иметь инструмент удобной и быстрой детализации - укрупнения.
Нужна индикация по разным критериям и срезам. Легкость в создании выборок подсистем.
Нужна карта боевых действий с переменным масштабом и подробностью информации.
Так можно находить узкие места, места сбоев и участки перегрева.
Как может асинхронное программирование при сети связей выиграть борьбу со сложностью?
№ 5403 07-10-2007 07:30 | |
Ответ на »сообщение 5402« (AVC)
___________________________
Конечно, правы.
Остается удивляться, почему все-таки это достаточно удобно. :)
Всё в мире относительно. Как Вы думаете, если бы, например, простановка ASSERT производилась автоматически (на основе более высокоуровневых сущностей) и при этом еще контроль и обработка ASSERT не сводились бы к примитивной интерпретации ран-таймом, было бы ещё удобнее? :)
Ну а если говорить о моём видении стратегии борьбы со сложностью, то, думаю, её вполне можно озвучивать уже сейчас. Это асинхронное программирование.
№ 5402 07-10-2007 07:14 | |
Ответ на »сообщение 5393« (Руслан Богатырев)
___________________________
>>>В Обероне есть модули и ASSERT. Остальное ручками и головой. Или я не прав?
Конечно, правы.
Остается удивляться, почему все-таки это достаточно удобно. :)
Вообще говоря, надо для начала разобраться в тех сложностях, с которыми требуется бороться. Понять, с каким из них стоит бороться. И какой ценой. А только потом уже разбираться с конкретными сущностями вроде модулей. Для начала выдвину такую гипотезу: с сложностями надо бороться раньше, ДО языка реализации. А на уровне языка это делать не ручками, а возлагать на соответствующие механизмы. Впрочем, мы забегаем далеко вперед. Обсуждать столь серьезный вопрос как бы между прочим не стоит.
Если бы Вы составили, например, список сложностей, которые программисту надо взять под контроль, это могло бы стать началом плодотворного обсуждения.
Согласен.
Попробую сформировать такой список.
А то прямо сейчас голову занимают скорее организационные вопросы: как наладить (на работе) учет ошибок и т.п.
№ 5401 07-10-2007 05:37 | |
Ответ на »сообщение 5396« (AVC)
___________________________
Да. Но ведь это другой (отдельный) язык?
Безусловно. И не один. Борьба со сложностью в рамках индивидуального программирования (и небольших проектов) вполне может решаться подходом языков-ядер (Оберона, Лиспа, Пролога и др.). Минимализм и концептуальная экономия.
Но как только речь идет о других масштабах и другом процессе разработки (коллективном, индустриальном), требуется предпринимать дополнительные шаги (сохраняя ценность языков-ядер и не допуская их "растворения" в объемлющей инфраструктуре). Главное, постараться не переборщить (когда сложность новых абстракций и инструментов превысит выигрыш от сложности самих проектов).
№ 5400 07-10-2007 05:32 | |
Ответ на »сообщение 5399« (AVC)
___________________________
А к чему этот вопрос? Переход на личности?
Полагаю, простое любопытство. Никакого криминала :)
№ 5399 07-10-2007 05:30 | |
Ответ на »сообщение 5397« (qwerty)
___________________________
Ответ на »сообщение 5394« (Руслан Богатырев)
___________________________
Поставлю вопрос по-другому. Есть ли в Сети вообще какие-либо исходники на модуле или обероне, написанные Вами?
А к чему этот вопрос? Переход на личности?
№ 5398 07-10-2007 05:21 | |
Ответ на »сообщение 5397« (qwerty)
___________________________
Поставлю вопрос по-другому. Есть ли в Сети вообще какие-либо исходники на модуле или обероне, написанные Вами?
А... так Вас интересую я, а не системы. С этого и стоило начинать. Насчет моих исходников в Интернете -- возможно, где-то и есть. В свое время (где-то в середине 1990-х) распространял свои библиотеки на Модуле-2, включая поддержку драйверов БД (Clarion) и мультиязыковое программирование для TopSpeed-компиляторов.
Впрочем, если интересует подход к написанию исходного текста и документированию, в качестве иллюстрации можете взглянуть на эту работу: "Золотой треугольник Паскаля" (2001) -- http://www.oberon2005.ru/paper/triangle.pdf
№ 5397 07-10-2007 04:54 | |
Ответ на »сообщение 5394« (Руслан Богатырев)
___________________________
Не вижу смысла Вас в этом разубеждать.
Поставлю вопрос по-другому. Есть ли в Сети вообще какие-либо исходники на модуле или обероне, написанные Вами?
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|