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

ailev

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

Mar 11, 2016 22:49

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

Leave a comment

Back to all threads

buriy March 13 2016, 12:50:33 UTC

У нас вместо молотка (логические представления) появился перфоратор (распределённые представления), и мы теперь хотим выкинуть все молотки и решать все задачи перфораторами? Вы сами-то со стороны себя слышите?
Со слабой связанностью проблема существовала всегда, и всегда она решалась проектированием и написанием интерфейсов. Интерфейс опирается на API. Что, неужели так тяжело придумать API и интерфейсы для нейросетей и для распределённых представлений?
Скажите, а вы объектно-ориентированным программированием занимались когда-либо, или только императивным подходом?

ailev March 13 2016, 15:48:37 UTC

Почему выкинуть молотки? Просто не ограничиваться молотками. Вы мои посты читаете всё время с концепции закрытого мира (closed world), а я их пишу исходя из концепции открытого мира -- традиционная различалка программистского/базоданческого и онтологического подходов. http://www.dataversity.net/introduction-to-open-world-assumption-vs-closed-world-assumption/... )

buriy March 14 2016, 08:31:55 UTC

>Почему выкинуть молотки? Просто не ограничиваться молотками ( ... )

ailev March 14 2016, 09:44:41 UTC

Я даже не буду оправдываться, что у меня есть представления о всех тех вещах, о которых вы говорите. И программы, с которыми я имею регулярно дело всю жизнь, это отнюдь не сто строк на Julia.

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

buriy March 14 2016, 10:24:32 UTC

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

>И программы, с которыми я имею регулярно дело всю жизнь, это отнюдь не сто строк на Julia.
Сто тысяч строк хоть одна, в которую вы исправления масштаба хотя бы несколько тысяч строк вносили, превышает?

ailev March 14 2016, 11:16:16 UTC

Я в посте определил, что является предметом моего методологического интереса: модульность (многоуровневая!) в коннекционистских системах и в связи с этим сдвиг от онтологических рассмотрений знания к эпистемологическим, как более адекватным. И что нужно пошевелить в системном подходе текущей версии (документированной в классических стандартах системной инженерии, типа ISO 15288, ISO 42010 и недавно OMG Essence), чтобы можно было обсуждать в том числе и разработку систем машинного обучения ( ... )

buriy March 14 2016, 14:55:08 UTC

>Я в посте определил, что является предметом моего методологического интереса: модульность (многоуровневая!) в коннекционистских системах ( ... )

ailev March 14 2016, 15:53:13 UTC

Ну, если вы меня уж так не понимаете, что нужно подробно расшифровывать -- то это не уместится в формат комментов в ЖЖ.

Можете проглядеть http://leon.bottou.org/slides/2challenges/2challenges.pdf, там немного есть про эту модульность по-английски.

То, что вы пишете о стандартах, я даже комментировать не буду.

buriy March 15 2016, 06:05:55 UTC

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

buriy March 14 2016, 08:32:24 UTC

>Объектно-ориентированное программирование -- немного совсем занимался, мне это никогда не нравилось ( ... )

ailev March 14 2016, 10:13:26 UTC

В языках обычно обсуждают гранулярность и модульность отдельно. 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 March 14 2016, 15:08:04 UTC

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

Back to all threads