![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
bowhillЕсть один тезис, который у сторонников ООП не получается опровергнуть, поэтому его стараются просто игнорировать — граф нельзя представить иерархией.
Статические иерархические модели можно отлично реализовывать средствами ООП, но в жизни их не так много, всё больше графы. Да ещё и динамические.
Это как поиск философского камня или вечного двигателя. Люди 25 лет вертят буквы S, I, T и H, уже мозоли натёрли, а счастья нет. Но вот-вот будет.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2016-10-09 04:25 pm (UTC)Но откуда граф?
Я помню, как дизайнил систему, и нарочно сделал ее такой, чтобы была иерархия.
Кстати, эта штука насчет графа и дерева, там еще есть логический аспект. Топологии Гротендика на дереве соответствуют поддеревьям, а на графе появляются еще этакие призраки.
no subject
Date: 2016-10-09 04:38 pm (UTC)А вот с чего уверенность, что проблемные области... э-э, вообще мэплятся на какую-то математику? Хоть Гротендикову, хоть чью. ;)
no subject
Date: 2016-10-10 06:07 am (UTC)no subject
Date: 2016-10-10 06:31 am (UTC)Особенно учитывая последние данные нейросаенса и искуственных нейросеток? ;)
no subject
Date: 2016-10-10 06:39 am (UTC)no subject
Date: 2016-10-10 07:09 am (UTC)no subject
Date: 2016-10-10 03:31 pm (UTC)no subject
Date: 2016-10-10 03:57 pm (UTC)То есть, это неявно предполагает некую изоморфность обычного языка и математики...
no subject
Date: 2016-10-10 05:58 am (UTC)С призраками так и получается, поверх графовой модели приходится придумывать некую существенно б́ольшую иерархическую, в которой можно как-то задавать необходимые связи. Просто для соответствия парадигме. И получаются во многообразии несуществующие призрачные сущности: структуры и отображения. И укрощение оных — большая часть проблем.
На мой взгляд, это вполне на поверхности, как история от IMS до System R.
no subject
Date: 2016-10-10 06:42 am (UTC)А классификация -- очень мощный (если не единственный) способ придать видимость ясности и однозначности любой бесформной области... хоть коллекционированию марок, хоть анализу генов.
Но это предает только видимость правильности, потому что ниоткуда не следует что наша классификация точно соответствует всем особенностям реальности.
А предложение заменить её "более обобщенными" графами -- ну да, это способно порешать какие-то мелкие задачи, но параллельно добавляет своих собственных.
Кстати, подумалось вот -- всякие кодировки черча, лямбды,
они ведь декларируются анаогичными машинам тьюринга по выразительности,
а у машин есть проблема останова -- интересно, а как она себя проявляет в них?
Не може ли такого быть, что вот все эти поиски типизированного граала -- просто игнорируют следующую их этого проблему,
и потому их поиски заведомо бесперспективны (ну, как Максим, думал что объедет ограничения Ф омега, потому что мол "но у нас ведь другая система")
no subject
Date: 2016-10-10 07:11 am (UTC)Мы сами налагаем два типа ограничений на модель, сокращаем размерности. А предметная область никуда не девается, упрощение языка приходится как-то компенсировать, вот химеры и вылезают.
no subject
Date: 2016-10-10 07:24 am (UTC)В смысле?
\\А предметная область никуда не девается,
Смелое заявление... особенно после того как вы сами выше настаивали на "предметы мэплятся в слова".
no subject
Date: 2016-10-10 07:52 am (UTC)И смелого особо ничего нет, например, если Эллочка Щукина знает тридцать слов, природа от этого не меняется.
no subject
Date: 2016-10-10 08:28 am (UTC)Раздел художественная литература и техническая,
в них соответственно свои подразделы...
А "по авторам, названиям, областям, жанрам",
свои иерархии соответственно, типа "авторы национальный и зарубежные" и т.п.
Вы пропустили между ушей мое про "иерархия это про классификацию"?
\\И смелого особо ничего нет, например, если Эллочка Щукина знает тридцать слов, природа от этого не меняется.
Природа не меняется, это безсомненно.
Но...
\\А предметная область никуда не девается, упрощение языка приходится как-то компенсировать, вот химеры и вылезают.
Разве вы не видите что суть именно в этом -- когда мы выбираем говорить о природе на том или ином языке, мы тем самым отсекаем "лишние" смыслы?
А потом удивляемся "и почему это абстракции опять протекли"... ;)
Или как вы для себя строите причину и следствие в этом случае?
Я так полагаю что никак, для вас это оказывается полностью за полем зрения.
no subject
Date: 2016-10-10 09:18 am (UTC)Полагать можно, но предметная область — это уже абстракция. То есть мы говорим о реализации одной абстракции средствами другой, ограниченной.
no subject
Date: 2016-10-10 10:08 am (UTC)Дык...
\\Полагать можно, но предметная область — это уже абстракция.
Как ноумен -- да.
Как феномен -- нет.
no subject
Date: 2016-10-10 10:23 am (UTC)no subject
Date: 2016-10-10 02:21 pm (UTC)no subject
Date: 2016-10-10 03:33 pm (UTC)λ x ((x x) (x x))
(λx ((x x) x)) (λx ((x x) x))
no subject
Date: 2016-10-10 03:53 pm (UTC)no subject
Date: 2016-10-09 04:30 pm (UTC)no subject
Date: 2016-10-10 06:05 am (UTC)no subject
Date: 2016-10-10 07:13 am (UTC)Она же какраз и существует, чтобы отсекать, прятать, делать невидимыми лишние связи. ;)
no subject
Date: 2016-10-10 08:07 am (UTC)Почему данные могут быть связаны c методами и между собой одним каким-то способом? Для наглядности, можно посмотреть на интерфейсы ( не UI), но проблема, конечно, шире.
no subject
Date: 2016-10-10 08:54 am (UTC)А какие еще вы знаете способы работы со связями?
Вот когда их 100500...
кроме их групировки и/или маскировк неактуальных?
\\Почему данные могут быть связаны c методами и между собой одним каким-то способом?
Туда же.
Какие еще вы знаете способы "связи данных с методами"?
no subject
Date: 2016-10-10 10:00 am (UTC)А если речь о вопросах инвентаризации, то связь эквивалентна записи, 100500 — это не так много.
no subject
Date: 2016-10-10 10:14 am (UTC)Имелось в виду -- способов работы со свъязями,
отличных от их группировки и/или выделения какой-то их части по какому-то принцыпу?
Вот возьмем те же графы.
Что ЕЩЕ можем с ними сделать, кроме:
ну там свести в табличку и отсортировать (по номеру вершин, по количеству ребер, по весам и т.д.),
или выделить некое помножество?
no subject
Date: 2016-10-10 10:56 am (UTC)А в простом смысле что можно сделать с декларацией “int i;”? Метаданные тоже данные.
no subject
Date: 2016-10-10 02:20 pm (UTC)no subject
Date: 2016-10-10 02:52 pm (UTC)Но вообще, в дообъектных языках связи не были иерархическими, и что делали? Программы писали.
no subject
Date: 2016-10-10 03:11 pm (UTC)а не как их можно использовать.
А графы, я упомянул как самый просто и наглядный формальный способ представления связей.
А про связи начал говорить, чтобы подвести к мысли -- что человек не может,
физически неспособен,
держать в голове и работать с таким количеством связей, которое предполагает даже обычное программирование.
И это при том, что эти связи -- по большей части даже не в базах данных хранятся -- потому что нет такой глубины и широты формализации процесса разработки и описания проблемной области,
и даже хуже того -- большая часть связей вообще неформальная -- находится или не находится в мозгах у человека.
И это было замечание к тому -- что человеку просто необходима инкапсуляция, группировка, типизация... называй как хочешь, но это все
в конечном итоге,
о попытке уменьшить количество связей с которыми нужно непосредственно работать человеку,
и сделать их кк можно ему понятнее и ближе...
И сделано это было для того,
чтобы намекнуть на некорректность постановки рядом инкапсуляции и наследования -- потому что это две большие разницы.
no subject
Date: 2016-10-10 03:43 pm (UTC)Процесс разработки — предмет непростой, но не надо думать, что все его сложности можно решить волшебным синтаксисом. Который заменит и процесс, и голову, и документацию, и средства, и всё прочее. Сам будет всё делать. На этот миф люди и ловятся.
И большие системы с тысячами сущностей пишутся отнюдь не только на инкапсуляции или наследовании. И если структура (условный csv) используется во множестве мест, то куда её инкапсулировать и зачем? К слову, структурирование и модульность никто не отменял.
no subject
Date: 2016-10-10 04:01 pm (UTC)Весь вопрос в том -- какого объема.
no subject
Date: 2016-10-10 04:21 pm (UTC)no subject
Date: 2016-10-09 08:41 pm (UTC)no subject
Date: 2016-10-10 05:03 am (UTC)no subject
Date: 2016-10-10 06:29 am (UTC)no subject
Date: 2016-10-10 07:04 am (UTC)no subject
Date: 2016-10-10 07:09 am (UTC)Собственно ООП и состоит в том чтобы это сделать (и стертые связи "прорисовать на коленке" - ну да гемморойно - но все-таки часть прорисовывать, а не 100%)
PS: Соственно "правильная иерархия" и состоит в том что "меньше прорисовывать"
no subject
Date: 2016-10-10 07:22 am (UTC)Это... довольно глупое утверждение.
Правильная иерархия должна (как минимум) включать все важные элементы проблемной области...
no subject
Date: 2016-10-10 07:23 am (UTC)no subject
Date: 2016-10-10 07:31 am (UTC)"правильная иерархия именно что и должна покрывать как можно больше графа" и "граф должен покрывать иерархию" -- совсем неодно и то же.
Потому что граф -- это наш внешний, совершенно произвольно абстрактный конструкт.
Вот у вас и получается,
что вместо разбирательства с подноготной проблемной области,
берется какая-то среднепотолочная абстракция -- и все остально потому пробуют втиснуть в неё.
Что, впрочем... вполне типичное поведение для программистов.
А потом они такие вылазят, и начинают крыть ЯП, ООП и вообще всех подряд... вплоть до фон Неймана,
за "огрниченность" и неспособность выразить их гениальные мысли в коде...
и дружно фапают на ФП. %)))
no subject
Date: 2016-10-10 07:34 am (UTC)no subject
Date: 2016-10-10 08:55 am (UTC)no subject
Date: 2016-10-10 09:24 am (UTC)no subject
Date: 2016-10-10 10:15 am (UTC)