Коннекционистская проблематизация системного подхода.

[ailev]

Основной путь, по которому системный подход проблематизируется, относится к переходу от локальных представлений системы к распределённым (http://ailev.livejournal.com/1228029.html). С распределёнными представлениями беда: вся подробно разработанная "механика" уровней системы с отношением часть

Comments

[buriy]

>Объектно-ориентированное программирование -- немного совсем занимался, мне это никогда не нравилось.
А оно и не было придумано, чтобы нравиться. В больших системах ООП применяется вынужденно, из-за отсутствия более вменяемых альтернатив. Вы можете это называть "модульностью", но взаимодействие этих модулей и будет тем самым ООП -- потому что вряд ли у вас получится иметь большой процент stateless-модулей в большой системе, а устройство взаимодействия stateful-модулей -- это и есть предмет ООП.
Ну а multiple dispatch в Julia подвержен ровно тем же проблемам, что и добавление методов в Ruby, и что мешают построению больших систем -- если набор методов объекта перестаёт быть локализованном в одном модуле и становится глобальным, то при увеличении числа модулей, количество конфликтов увеличивается экспоненциально. Вот сделали вы универсальный метод toJSON() у объектов, хотите дерево объектов сериализовать в JSON -- но одна библиотека для этого дополняет своим toJSON интерфейс стандартного объекта, а вторая библиотека -- другой реализацией (например, одна библиотека список выводит в сортированном порядке, вторая -- в исходном порядке). Глобальный конфликт реализаций. Что будете делать? Это именно та проблема, по которой "произвольная отправка сообщений между объектами" хороша только в маленьких программах.

[ailev]

В языках обычно обсуждают гранулярность и модульность отдельно. Multiple dispatch это про гранулярность больше, а вот модульность (в том числе предотвращение конфликта методов и управление видимостью имён) реализована так: http://docs.julialang.org/en/release-0.4/manual/modules/

Про отправку сообщений вы неправы, ибо она как раз для больших программ обычно делается: все эти микросервисы как раз в эту сторону. При обсуждении языков как раз критика и идёт, что подобного сорта конструкции для programming-in-the-large (погуглите) не поддержаны языком, а делаются поверх языка, что некузяво.

Ежели чего, то вот неплохая аннотированная подборка ссылочек на работы Alan Key, там раздел есть и цитаты про ООП: http://mythz.servicestack.net/blog/2013/02/27/the-deep-insights-of-alan-kay/

[buriy]

Основная проблема в программировании для опытных программистов -- не максимальная свобода действий, а борьба со сложностью всеми доступными методами. Кей про это ничего не пишет, как я понимаю.
Для максимальной свободы действий давно есть C++. Хотите -- стреляйте себя в ногу хоть по десять раз на дню. Но вам придётся помнить, кто каким объектом когда владеет, чтобы вовремя объект удалить. Это сложно.
А микросервисы уменьшают сложность обновления модулей, изолируют ошибки. Но передачу сообщений они лишь усложняют, т.к. вместо надёжного канала внутри одного CPU у нас теперь нестабильный канал через границы CPU.