Ответ на »сообщение 5404« (Как слышно? Приём!)
___________________________

Как может асинхронное программирование при сети связей выиграть борьбу со сложностью?

Кто сказал, что в этой борьбе можно выиграть? :)

Тезис довольно простой: мы в значительной мере создаем себе сложности сами. Почему? Потому что так проще. :) И выгоднее.

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

Сложные вещи делать проще. Простые -- сложнее. Написать статью по нетривиальной проблеме на половину журнальной полосы много сложнее, нежели статью на несколько полос.

Асинхронное программирование -- лишь одно из звеньев цепи. Правда, очень важное. Это несколько иной подход к мышлению, к решению задач, к реализации проектов. Подход, в котором вместо "раньше - позже" преимущественно фигурируют причинно-следственные связи.  Он не отвергает синхрон, просто становится над ним, становится первичным.

Асинхронное программирование лежит в русле идей В.Е.Котова, в русле работ по проекту МАРС середины 1980-х. Увы, в том проекте большей частью вынуждены были ограничиваться демонстрацией, "военным парадом" тех заделов, которые были созданы в предшествующие годы.

Асинхронное программирование может пронизывать все ведущие парадигмы (включая и ИП), ибо оно особенно важно на архитектурном уровне, при высокоуровневой композиции сущностей. Асинхронное программирование не только создает практически идеальную основу для автоматического распараллеливания, но и позволяет задействовать математический фундамент для ключевых, а не просто второстепенных вещей.

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

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

>>>Ну а если говорить о моём видении стратегии борьбы со сложностью, то, думаю, её вполне можно озвучивать уже сейчас. Это асинхронное программирование.

Асинхронное -- в каком смысле? (Вопрос задан в свете »сообщение 5387«.)

>>> Борьба со сложностью в рамках индивидуального программирования (и небольших проектов)
>>> вполне может решаться подходом языков-ядер (Оберона, Лиспа, Пролога и др.).
>>> Минимализм и концептуальная экономия.

>>> Но как только речь идет о других масштабах и другом процессе разработки
>>> (коллективном, индустриальном), требуется предпринимать дополнительные шаги

А не путается ли тут сложность проекта (объективная) и сложность пастьбы котов (субъективная)?
Очень опасная путаница. Задумывался UML как средство создания сложных моделей.
Затем превратился в средство контроля за разработкой. Именно это и погубило UML.

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

С другой стороны - удобство и наглядность графического представления (по аналогии с презантациями)
были мгновенно впитаны менеджерами проектов. И UML стал игрушкой офисного планктона, а жаль.

Нужен надязык, но уже не UML. Там всё обросло ракушками администрирования.
Смотреть надо в сторону сетей Петри и чего-то более неформального и нечёткого.

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

Как может асинхронное программирование при сети связей выиграть борьбу со сложностью?

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

Конечно, правы.
Остается удивляться, почему все-таки это достаточно удобно. :)

Всё в мире относительно. Как Вы думаете, если бы, например, простановка ASSERT производилась автоматически (на основе более высокоуровневых сущностей) и при этом еще контроль и обработка ASSERT не сводились бы к примитивной интерпретации ран-таймом, было бы ещё удобнее? :)

Ну а если говорить о моём видении стратегии борьбы со сложностью, то, думаю, её вполне можно озвучивать уже сейчас. Это асинхронное программирование.

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

>>>В Обероне есть модули и ASSERT. Остальное ручками и головой. Или я не прав?

Конечно, правы.
Остается удивляться, почему все-таки это достаточно удобно. :)

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

Если бы Вы составили, например, список сложностей, которые программисту надо взять под контроль, это могло бы стать началом плодотворного обсуждения.

Согласен.
Попробую сформировать такой список.
А то прямо сейчас голову занимают скорее организационные вопросы: как наладить (на работе) учет ошибок и т.п.

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

Да. Но ведь это другой (отдельный) язык?

Безусловно. И не один. Борьба со сложностью в рамках индивидуального программирования (и небольших проектов) вполне может решаться подходом языков-ядер (Оберона, Лиспа, Пролога и др.). Минимализм и концептуальная экономия.

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

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

А к чему этот вопрос? Переход на личности?

Полагаю, простое любопытство. Никакого криминала :)

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

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

Поставлю вопрос по-другому. Есть ли в Сети вообще какие-либо исходники на модуле или обероне, написанные Вами?

А к чему этот вопрос? Переход на личности?

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

Поставлю вопрос по-другому. Есть ли в Сети вообще какие-либо исходники на модуле или обероне, написанные Вами?

А... так Вас интересую я, а не системы. С этого и стоило начинать. Насчет моих исходников в Интернете -- возможно, где-то и есть. В свое время (где-то в середине 1990-х) распространял свои библиотеки на Модуле-2, включая поддержку драйверов БД (Clarion) и мультиязыковое программирование для TopSpeed-компиляторов.

Впрочем, если интересует подход к написанию исходного текста и документированию, в качестве иллюстрации можете взглянуть на эту работу: "Золотой треугольник Паскаля" (2001) -- http://www.oberon2005.ru/paper/triangle.pdf

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


Не вижу смысла Вас в этом разубеждать.

Поставлю вопрос по-другому. Есть ли в Сети вообще какие-либо исходники на модуле или обероне, написанные Вами?