Comments 28
Первоначально нам необходимо познакомиться с предметной областью, узнать, из чего она состоит. Так в мастерской мы учимся различать конкретные инструменты, материалы, изделия друг от друга. Нам пока непонятно до конца их назначение, мы их ещё в руках не держали, но если мы не научимся их различать, то не поймём и дальнейшей премудрости. Аналогично, в разработке программного обеспечения мы знакомимся с понятиями переменной, массива, цикла, ссылки, составных типов данных. Учимся различать данные, переменные, константы и определения.
"Терминология"
Простое обьяснение от себя. Структуры данных вроде делятся на две категории - атомарные, которые в одном байте или слове находятся и сложные. Последние в свою очередь с доп. информацией или без оной. Последние - есть массивы, первые - всякие разные сложные структуры, где и классы, и всякие списки итд. Ничего из этого не увидел в вашей статье. Потому что усложнение любой структуры второй категории - будет постоянно происходить.И их сложность - не есть само по себе - эволюция. Потому что для решения современных задач создаются не совсем сложные структуры и сегодня. А такие вещи как базы данных или например нейросети - это уже больше модели, чем просто структуры.Потому что в них включается не только сохранение данных и их организация, но и методы с их работой, и обязательно связи между разными вершинами и рёбрами итд.
А примеры с улитками или с бобами в корзиночке - это как-бы для детей.
В статье рассматриваются не типы данных, а структуры, т.е., многообразие составных типов данных. Первый рассматриваемый уровень - это уже кортеж.
И в ней утверждается (не могу сказать "показано", потому что обоснованию данного заключения посвящена книжка, а здесь обсуждается лишь сам феномен), что традиционный тезис о "бесконечном усложнении" - ложный. Т.е., в отношении того, что мы называем "данными" существуют только 4 хорошо формально различимых уровня сложности их организации.
В ракурсе той интерпретации "сложности", которая описана в статье, дальнейшее усложнение возможно, но данные, которые будут обрабатываться на следующем уровне, будут хорошо формально (да и на глаз) различимы от данных текущего уровня, и, строго говоря, данными уже являться не будут.
Буду конкретен: у нас уже появился этот новый тип "пост-данных": нейросеть. Мы его пока слабо отличаем от алгоритма - потому что это первый уровень и нейросети для нас, как бы, единичны, каждая - отдельное произведение труда и мысли. Но, на деле, это - новый тип данных, который вполне сериализуется.
Вы сами отмечаете, что цитата: "А такие вещи как базы данных или например нейросети - это уже больше модели, чем просто структуры". Именно об этом и идёт речь - что это как бы данные, но как бы нет, это уже комбинация всех четырёх типов данных предыдущего уровня, получившая новое качество. Поскольку мы говорим, что это уже "не совсем данные" - это переход на новый эволюционный виток.
Но как мы будем их пересчитывать? Как будем складывать и преобразовывать? Что будем делать с тем, что этот тип имеет недетерминированое значение? Это и есть "улитка". Не могу без метафор - есть такой грех :)
А то, что Вы назвали усложнением - это лишь количественное наращивание, т.е., качественного скачка не происходит. Это как мы можем создать реляционку на sqlite, или вообще на коленке, а можем на Oracle RDBMS - с огромным количеством таблиц и отношений, но ни та, ни другая не будут обладать векторными или субструктурными свойствами (а когда начнут, то сразу выйдут за рамки только лишь реляционности).
Имитация постреляционных свойств без выхода из реляционной парадигмы возможна (1C, IBSO, которые, по сути, имитируют фреймовую структуру), но затратна. Собственно, эта затратность и вызвана скачком сложности, мы в этот момент перестаём использовать SQL для непосредственного решения задач и используем его просто как неизбежный костыль.
Стаття по суті являє собою вперте натягування сови на чотириповерхову хрущовку.
Практична цінність викладених в ній знань під великим сумнівом.
А вот хороший вопрос, так что отвечу:
Ребёнок, который учится складывать пирамидку - бублики разного размера на палочку, приобретает очень важный навык, который необходим в современной жизни: понимание, что нечто одинаковое, может различаться и может быть упорядочено. С этого навыка начинается любой раздел научного знания.
Поэтому начать понимать про различение и упорядоченность структур хранения данных - это самоценный базовый навык, который позволяет формально, а не интуитивно подходить к анализу технических систем в этом ракурсе и видеть их генезис - а значит, предсказывать развитие.
То есть эта статья должна была принести пользу лично вам, как складывание пирамидки приносит пользу ребёнку?
Странный вывод. Вроде как показываю уже сложенную пирамидку... разве нет?
Так ребёнок тоже показывает взрослым уже сложенную пирамидку, и его хвалят.
Целевая аудитория - дети, ещё не сложившие свою пирамидку
Так для развития ребёнку нужно самому сложить пирамидку, а не смотреть, как её сложил сын маминой подруги. Сама по себе пирамидка ценности не имеет, важен опыт складывания.
Это не так. Ребёнок тоже сперва видит как правильно, потом повторяет как умеет, пока не получится. И не ребёнок. И в любой предметной области. Но всегда есть альтернатива - поспорить на отвлечённые темы.
И вы предлагаете читателям хабра, среди которых достаточно много профессионалов-айтишников, учиться у вас складывать пирамидки?
Вы так ёмко выразились, что я чего-то даже затруднился выбрать, на какое слово отвечать. Для начала замечу, что сегодня профессионал-айтишник, который не учится новому, не имеет будущего. Хабр - площадка, на которой каждый предлагает то, что считает интересным для других. И нет никакого правила, чему сегодня учиться нужно, а чему нет - каждый выбирает по своему разумению. Что же до пирамидок, то это лишь упрощающая метафора. Но стоит ли на основе лишь метафоры недооценивать полный контекст?
Метафора лишь позволяет передать мысль :-)
А если уйти от метафор – я бы предложил, раз уж вы позиционируете свою классификацию, как что-то новое, оформить всё это, как научную работу:
Литературный обзор – что сделали предшественники.
Какую задачу они не решили?
Ваши предложения по решению.
Выводы
.
Без пункта 1, собственно говоря, и обсуждать нечего.
Upd: ну или можно, поскольку мы тут скорее ремесленники, чем учёные, переработать статью для ремесленников: вот, мол, такой-то подход, он приносит такую-то пользу в вашей работе.
Вопрос интересный. Но скучный :)
На самом деле, Вы подсказали мне тему следующей статьи. Вот по этим вопросам и пройдусь.
Спасибо.
PS. Спойлером, бегло, чтобы не завешивать: Главные предшественники Гегель, Маркс, Альтшуллер. Решали проблему измерения качеств. Хотя вывели базовые законы, недостаточно обобщили их и не решили задачу исчисления. В результате у нас в естествознании, как в анекдоте про Вовочку: "ж**а есть, а слова нет", т.е., качества есть, а считать и прогнозировтаь их превращения на пальцах, без тяжёлого моделирования мы не можем. Фантастического в этом ничего нет - в статье буквально на пальцах и показано, как это делается. Практикой поверено. Диалектикой обмазано чуть более чем полностью. Невиданных сущностей не вводится. Но да, всю эту подоплёку имеет смысл размотать подробнее.
Вангую, что вас опять будут унижать, а вы будете говорить "мою музыку никто не понимает, не доросли ещё до моей музыки".
Ох... ну эта музыка - да... :)
Но здесь всё не так трагично...
Это знание не только лишь в моей голове - его разделяют и развивают несколько человек - настолько разных, что его рациональность и передаваемость для нас подтверждены. Поэтому я озабочен не тем, чтобы что-то кому-то доказать, а тем, чтобы зацепить тех, кто тоже сможет увидеть новую каритнку. Дело-то стоящее - там много интересного открывается на вполне практическом уровне. В т.ч. и в ИТ.
С этим сложно, конечно. Самостоятельно "проснувшихся" крайне мало. Они хорошо заметны по риторике, но их сразу так торкает на неприземлённые фантазии, что уже не поймать. А у "спящих" нет вопросов к этой теме. Но вопросы будут возникать всё чаще и лет через 20 уже будет поздно пить боржоми - слишком много станет вопросов без ответов, в т.ч. бытовых и слишком много времени будет потеряно для развития новых научных направлений. Я тенденцию-то не первый год отслеживаю.
В то же время, часть моих камментов пойдёт в нарезку на статьи в другом месте, а кое-что - во второй том книжки, из которого я вот эту статью дёрнул. Так что я, тут распинаясь, не совсем в накладе.
А объяснялку для ИТ-шников подобрать хочется. Сам ИТ-шник :)
Понимаете, способность складывать пирамидки в одной области (например, бублики на палочку) вовсе не означает способности складывать пирамидки в другой области (например, порядок бесконечностей). Поэтому в каждой области знаний обоснованная упорядоченность имеет отдельную ценность и требует понимания своего предмета различения.
Сможете ли предъявить "взрослых", которые могут складывать пирамидки в области эволюционных процессов описанным образом и (как доказательство "взрослости") способны объяснить, почему это так и почему это работает?
Статью написал для тех, кому это может быть интересно.
аналіз і синтез, індукція і дедукція... і взагалі методологією пізнання займається наука гносеологія. і там вже все давним-давно сказано. ви ж такий прийшли і вуаля: ось вам мій супер-пупер триколісний лісапєт, але без сідушки... так, я зрозумів що у вас саме таке бачення і саме під таким кутом зору, але навколишній світ трохи складніший, ніж у вашому уявленні про нього, хоч при цьому й описується простіше ніж знову таки у вас. це тому що над відповідними моделями, які б описували реальність вже ґрунтовно на фундаментальному рівні попрацювали професіонали.
Если коротко, то "нет". Есть большая разница между тем, чтобы объективировтаь феномен (для этого необходимо его увидеть целостно) и тем, чтобы, когда феномен уже описан, умно' объяснить его отдельные элементы, не сшивая их в целостную картину.
Материал статьи можно отлично разобрать по трём законам Диалектики (поэтому я не знаю, куда уж там, как Вы говорите, "проще"), но нельзя с их помощью этого первоначально увидеть - не хватает важного звена.
Современный уровень гносеологии не позволяет объективировать то, что описано в статье. Вероятно этим и объясняется, что таких материалов "специалисты" не выпускают. Если я не прав - приводите конкретику и практические результаты.
Мы его определяем как "процесс", т.е., по своему уникальное «живое» явление с жизненным циклом. При всей фантастичности, это достаточно простое умозаключение: ведь если у нас есть нечто, способное отражать отрезок времени, как целое, т.е. жизненный цикл, то оно само обязано быть, как минимум, отрезком времени с жизненным циклом. А отрезок времени, имеющий жизненный цикл называется "процесс".
Не хочу быть букой/бякой, но это живое явление очень давно существует в BPM-системах. А они довольно таки старые, как концептуально, так и с точки воплощения в реальном мире
А в целом ... сложно понять вашу мысль, честно. Какие-то 4 фазы. Почему 4? Ну это ладно.
Я могу ошибаться, но структуры данных никуда не делись и никак особе не приросли. Есть, как вы и написали тривиальные структуры в виде атомарных типов, если структуры. Массивы, списки, мапы.
Объекты - это развитие определенное парадигмы программирования, которая предложила смотреть на данные определенным образом. Но тут первична парадигма, а появление "объекта" - прямое следствие. Т.е. уже на этом примере может показаться разумной идея идти не от данных, а от "парадигм". Так как именно мышление определяет остальное. То как вы мыслите, определяет то, чем вы оперируете. Попробуйте зайти с этой стороны
К примеру, реляционная алгебра и ее конкретное порождение в виде SQL создает совершенно иной тип объекта (отношение) и операции с ним. Но не потому что "структура" первична, а наоборот.
Если философски - то это даже скорее как инь и янь, так как мышление и язык по сути связаны. Вы мыслите на языке и оперируете терминами языка
А у вас, сорри за прямоту, вышло что-то вроде как, если бы вы заглянули на кухню ресторана, подняли пару крышек и выбежали радосно описывать увиденное как полную картину мира
как, если бы вы заглянули на кухню ресторана, подняли пару крышек и выбежали радосно описывать увиденное как полную картину мира
и кусок мяса, который лежит на дне и не приметил-бы 😊
Ну, как бы, неудивительно, что в BPM, которая "process management" есть понятие процесса. Но предмет BPM - это процессы реального мира, либо процессы, на которые существенно влияет реальный мир. Мы же здесь говорим о появлении технических, пост-алгоритмических систем с такими свойствами.
Ну и само существование BPM тоже не должно удивлять. Задачи-то стоят.
С другой стороны, вот цитата: "Система корпоративного управления бизнес-процессами должна обеспечивать полноценную программную поддержку трёх ключевых этапов работы с любым бизнес-процессом: моделирование, исполнение и мониторинг."
И вот это, прошу прощения, чистая эмпирика. Т.е., возвращая Вам Ваш вопрос: "Почему 3?".
Конкретно в отношении BPM - куда дели регулирование модели на основе анализа собираемых данных? На каком основании тот кто настраивает модель в рамках BPM вынес себя за скобки системы? Зная ответ на вопрос "Почему 4", мы видим это искажение и понимаем, что без того, чтобы консультант стал частью системы, а не внешним управляющим узлом, дальнейшее развитие направления будет стагнировать.
Про то, что объект - следствие парадигмы, это не совсем так: объект соответствует объектной парадигме и при появлении парадигмы, появление объектов было неминуемо. Отставание артефакта во времени от идеи, или, иногда - наоборот, не имеет значения для конечного результата.
По остальному - можно и так смотреть, но это традиционный эмпирический взгляд, который основан на стратегии различения "на глаз это разное". В статье предлагается взгляд, ограниченный рамками универсального формального принципоа. Можно его принимать, можно - нет, дело личное. Если принимать, то в том, что Вы перечислили можно просто посчитать сложность адресации. В списке - 1, в хэше - 1, в массиве - 2. В реляционной алгебре - тоже 2 и не более того.
Давайте по частям, хотя, скажу честно, я вас с трудом пониманию. Вы как будто из какой-то далеко ушедшей "вперед" кафедры теориии програмирования, где читаются курсы имени себя любимого
Конкретно в отношении BPM - куда дели регулирование модели на основе анализа собираемых данных? На каком основании тот кто настраивает модель в рамках BPM вынес себя за скобки системы?
Если говорить об системах этого класса (я обладаю кой каким опытом работы с IBM и PEGA), то это как раз нет так. Методология внедрения таких систем от вендора явно говорит об итеративном улучшении качества реализованных процессов на основании определенной последовательности действий. А платформа старается максимально этому помощь, и в том числе, сблизить в одну точну "бизнес" и ИТ. Поэтому кто и куда выносит - я не знаю. Ну честно. Сложно комментировать ответ, в котором содержиться, скажем так, очень странное утверждение. Ну ладно, это не важно, хотя ясно, что вы, делая "странный" вывод, дальше уноситесь в своих умозаключениях совершенно далеко :)
Про то, что объект - следствие парадигмы, это не совсем так: объект соответствует объектной парадигме и при появлении парадигмы, появление объектов было неминуемо. Отставание артефакта во времени от идеи, или, иногда - наоборот, не имеет значения для конечного результата.
Я не хочу заниматься решением парадокса о первородстве яйца и курицы. Сорри. Это не важно. Важно единство парадигмы и того, чем она оперирует. Хотите рассуждать о языках программирования - идите с этой стороны, иначе вы выглядите очень странно. Ну реально, пример з заглядыванием в пару кастрюль по прежнему актуален
По остальному - можно и так смотреть, но это традиционный эмпирический взгляд, который основан на стратегии различения "на глаз это разное".
Оно разное не на глаз. Оно разное по сути. Т.е. есть базовые структуры, оперируя которыми пишется логика. Для привычных языков программирования массивы, списки и хеши будут, так как они просто пришли из банального способа как-то описывать множества. Те, кто пошли дальше, придумали объекты, отношения, функции и т.д. К примеру, "окно" сообщений появилось, когда появились потоки. Нормально и логично.
Ваше умозаключения - это просто фрагменты Теория управления — Википедия (wikipedia.org) , тут можно копать практически неограничено всю жизнь, но ... либо вам стоит этим заняться плотно, и прийти сюда через пару лет, когда вы сможете широкой аудитории рассказать все тоже самое (только без фраз в стиле "Переход от глубоких нейросетей к трансформерам с механизмом внимания знаменует замыкание генезиса фаз логики управления"), либо не уйдете, и тогда не стоит и пытаться :)
Лично я с этим закончил на 4м курсе, так как понял, что уйду в более практическую область "автоматизации" и вообще, внедрения более простых и понятных бизнес систем. Курс был сложным и очень математикоемким. Поддержать дискуссию сейчас я уже не смогу, так как сейчас с трудом с помощью гугла вытягиваю на уровень троеечника первокурсника. Сорян
Да я вижу, что с трудом. Понимаете, я вот описал некую систему классификации, подвёл под неё базис: чем различается, как упорядочивается... ну вот есть, получается, ещё такая, вдобавок ко всем прочим Вам известным. Откуда я её взял? Коллектив авторов над этой темой работал 5 лет. Я тут просто рассказываю то, что релевантно тематике Хабра и, с моей точки зрения, важно для развития отрасли и просто интересно.
Вот Вы говорите "такое всем известно и можно без этого". И, как бы, нет, не известно: есть парафразы у Адизеса, в ТРИЗ и в других источниках, но обобщения и обоснования его валидности нигде нет. И про тот аспект сложности, о котором рассказываю - тоже нигде нет, чтобы он в эволюционной последовательности был дан.
Но да, можно без этого. И дальше Вы описываете, как без этого можно - там BPM, SQL и всё вот это. Я не специалист в BPM, но в SQL, LISP, Erlang, Prolog, а также менее экзотичных и более современных языках я чутка понимаю и мы в этом с Вами примерно одну картину видим. Но чего проку её обсуждать-то? Она и так всем известна и понятна.
Поэтому я тут и предмета спора-то не вижу.
Про BPM - я не обсуждаю, приносите ли вы людям пользу, или нет, я обсуждаю степень понимания отраслью того материала, с которым она работает. И вот я взял цитату у уважаемых людей, а из неё видно, что в голове нет полной структуры деятельности. Только об этом и написал. Никак не критикуя полезность BPM для бизнеса в её текущем виде. Можно и так, конечно.
Вдогонку:
Оно разное не на глаз. Оно разное по сути. Т.е. есть базовые структуры, оперируя которыми пишется логика.
А чем Вы отличаете суть одного инструмента от сути другого? Кроме того, что можете сказать "это очевидно на взгляд".
Например, мы можем написать сложную программу вообще без массивов - это тогда необходимый инструмент, или нет? Если мы говорим о научном подходе, у Вас должны быть формальные критерии различения методов.
Я приведу пример с цветом: для нас "красный" очевидно отличается от "синего", но это и есть эмпирика, а наука начинается, когда мы узнаём о частоте световых волн.
Суть моего утверждения в том, что все эти структуры данных, даже те, которые кажутся вам очевидно различными, принадлежат к одному классу "структуры данных систем обработки данных". И предлагается вот этот критерий различения их по "частоте", т.е., по уровню сложности. Это никак не отменяет всего того, что мы уже знаем о средствах программирования, но делает картину чуточку яснее и формальнее.
Смотрите, классификация по неким свойствам возможна либо даже имеет смысл и он ней можно говорить, если внутри класса элементы идентичны в контексте рассматриваемых свойств. Это просто суть классификации. Мы заменяем рассматривание элементов по отдельности, который может буть миллион, либо вообще бесконечность какого-то порядка, на рассмотрение счетного и желательно небольшого числа классов, считая что результаты для класса можно смело применять для всех элементов, которые в него входят.
Зачем понятно. Рассмотреть даже миллион просто невозможно в пределах человеческой жизни, и надо как-то радикально сократить число до разумного. У вас вышло 4 уровня. Ок. Пусть будет. Но в чем суть рассмотрения? Вы свели все структуры в 4 уровня, но как это применить.
Я приведу другой пример. Допустим собаки. Есть породы, стандарты. Это имеет смысл например, если вы едете на выставку. Вы соревнуетесь с представителями своей породы/пола. Это логично. И получается такая классификация применима на практике и более того, она применяется. Но вот кто-то решил ввести классификацию собак по длине хвоста относительно высоты холки. И 4 градации, условно до 20% от высоты, до 40% от высоты, до 60% и свыше. Математически все верно. Введение классификации возможно, показатель, взятый за основу измерим. Будем также считать, что пустых классов нет и в каждом из них будут представители. Но как ее применить? Всем по фиг.
Тоже самое и с вашим примером. Вы как-то поделили, измерили. Да, пусть будет. В чем смысл? Классификация ради классификации? Да, мы получили некий viewpoint на уже существующие знания. Но чем он лучше варианта делить структуры по количеству букв в их названии на английском языке?
Фразы вроде "Переход от глубоких нейросетей к трансформерам с механизмом внимания знаменует замыкание генезиса фаз логики управления" не добавляют понимания. Это прекрасно звучит на каком-нибуть филосовском симпозиуме либо с трибуны политбюро, когда все "свои" и ожидаются только бурные апплодисменты.
Смотрите, классификация по неким свойствам возможна либо даже имеет смысл и он ней можно говорить, если внутри класса элементы идентичны в контексте рассматриваемых свойств.
В статье таким свойством является структурированное хранение данных в языке программирования. И рассматриваются способы организации таких структур. Это даже вынесено в заглавие.
Соответственно, не зависимо от того, кажутся ли кому-то некие инструменты программирования одинаковыми, или совсем разными, если они предназначены для хранения структурированных данных в ЯП, они попадают в рассматриваемое множество.
Но в чем суть рассмотрения?
Суть рассмотрения в том, что некое множество, прежде представлявшее собой "россыпь", в которой каждый элемент был самостоятельным феноменом, теперь поддаётся обобщению и упорядочиванию.
Вы свели все структуры в 4 уровня, но как это применить.
Во-первых, разбивка структур данных по уровню сложности даёт возможность прогнозировать организационно-вычислительную нагрузку, которую вызовет попытка запаковать в них те, или иные данные.
Например, попытка запаковать реляционные данные в списки, попытка запаковать объекты в реляционку - всё это возможно, но вызывает избыточное кодирование, в т.ч., алгоритмический хардкодинг тех взаимосвязей, которые в структурах данных более высокого порядка могли бы быть параметризованы.
Например, в объектных системах (3 уровень) мы имеем возможность реализации полиморфизма, а в более простых структурах данных (реляционках, например) нам пришлось бы (и приходилось, и приходится до сих пор) его имитировать if-ами, тестирующими извлечённый объект на название "класса".
Некоторым людям (в зависимости от технических склонностей), это кажется очевидным, но далеко не всем. И даже те, для кого это очевидно, не могут ответить на вопрос "почему"? Выдвинутый критерий это позволяет.
Аналогичный по информативности критерий уже используется для оценки эффективности алгоритмов: сложность O(1), O(n), O(n x n) и т.п., которая показывает порядок числа итераций для получения ответа по выборке n элементов. Тема включена в академические курсы.
Приведу пример не совсем из области низкоуровневых структур данных, но использующий этот же принцип: при внедрении на предприятии информационной системы, эмпирически мы знаем, что на крупном предприятии необходимы и BPM, и ERP, а на предприятиях до 100 человек внедрение ERP невозможно по причине того, что оно не потянет тотального учёта. Предлагаемый в статье подход, приложенный к описанной задаче, позволяет сопоставить сложность отношений на предприятии (есть такая методика диагностики) со сложностью информационной системы и это будет более точная оценка, потому что иные предприятия и на сотне человек не достигают необходимой организационной зрелости. Соответственно мы снижаем уровень экспертной ошибки.
Во-вторых, в последовательность вводится эволюционный принцип. То самое "почему 4". 4 - потому, что развитие Диалектического закона даёт 4 (две взаимосвязанные пары), а не какое-то другое число. Этому посвящена книга "Наука складности" (гуглится). Может, потом отдельной статьёй это опишу. Так-то не сложно, но не шибко коротко. В рамках обсуждения это не важно.
А важно то, что мы понимаем, что за 4 уровнем в обработке данных искать нечего, понимаем, что 4+1 уровень будет работать уже не с данными, а с какой-то более сложной сущностью, которую нужно не проворонить в академическом поле. Понимаем, что на 4+1 уровне нам необходимо объединить структуры данных всех четырёх нижележащих уровней.
Например, ИИ сегодня не использует 1-3 уровни в системах обучаемой памяти, а пытается их имитировать через 4й. Это косяк, который однажды исправят и получат очередной прорыв в функционале. Понимаем, что за 4+1 пойдёт 4+2 и какие у него будут свойства и, через какое-то время - возможно даже поймём, каких факторов не хватает для его запуска. Это как Закон Мура, который сейчас полощут (и ведь он не перстал работать, но почему-то потерял значимость).
В-третьих, например, цикл математических открытий от создания теоретической базы до практического применения составляет, в среднем, 150 лет (по Яну Стюарту), поэтому, кто знает, где ещё пригодится?
Ну, и в-четвёртых, это самоценно. Я выше в комментариях писал: https://habr.com/ru/articles/765240/#comment_26027608. Иными словами, любая законная (не надуманная) упорядоченность в голове освобождает её от лишних мифологических сущностей.
Я приведу другой пример. Допустим собаки. Есть породы, стандарты. Это имеет смысл например, если вы едете на выставку.
Предположим, некто провёл исследования и обнаружил, что хвосты, которые короче 70% высоты не выполняют функцию заметания следов (задача гипотетическая и я тоже пофантазирую), а хвосты которые короче 15%, дают существенный прирост коммуникативной способности (ими чаще махать можно). А это уже функциональные признаки, которые не просто по красоте, а весьма конкретно влияют на специализацию породы.
Практично ли это? - Вполне. Например, только лишь на основе длины хвоста Вы теперь сможете сказать о породе больше, чем эмпирики выучили в институте.
Также это позволяет, например, включить данный признак в планирование селекции для выведение новых функционально специализированных пород.
Что тогда делать с прежней классификацией? - Ну, если она была для чего-то нужна, то пусть будет. А если была классификация ради классификации - то причислить к числу "наивных верований" и на помойку.
Фразы вроде "Переход от глубоких нейросетей к трансформерам с механизмом внимания знаменует замыкание генезиса фаз логики управления" не добавляют понимания.
Тут Вы правы. Сам написал, что нельзя оперировать непонятными понятиями до их объяснения и сам нарушил. Спасибо, учту. Но позвольте объяснить, дело не такое уж сложное...
При проектировании технических систем любого уровня - от самых простых, типа соединения черенка и полотна лопаты, до самых сложных мы используем логику, т.е., методологию, основанную на строгих причинно-следственных связях. Логика позволяет нам создавать управляемые системы (и только такие).
Любые технические системы, без исключений, управляемые и управляющим звеном у них всегда являлся человек. Даже, казалось бы, полностью автоматизированные технические системы не имеют смысла до включения в их контур человека в виде водителя, оператора, потребителя и т.п.
Тем не менее, техническая система включает в себя внутреннее управляющее (согласующее) звено. В случае с лопатой - это тулейка с гвоздиком. В случае сложной технической системы - это система автоматизированного управления (САУ), на одном конце которой интерфейс, а на другом - исполнительные механизмы.
До четвёртой фазы развития технических систем управляющее звено системы несёт вспомогательную функцию, а в четвёртой фазе получает ведущую роль в виде САУ.
Алгоритмические системы являются вершиной автоматизированного управления, т.е., появляются в четвёртой фазе развития САУ.
Глубокие нейросети (DNN) являются венцом развития алгоритмических систем и, среди прочих программных инструментов, наиболее предназначены для генерации управляющей информации.
Поскольку согласно фазовому закону, фаза "управления" считается четвёртой и последней в эволюционном цикле развития, то у нас и развитие технических систем и развитие алгоритмических систем близко к завершению.
Дальше они будут тиражироваться, они получат гораздо большее разнообразие, но чего-то супер прорывного в них уже не будет. Это не такое смелое утверждение, как может показаться - современная атомная станция - это по прежнему лишь паровая машина и общее количество способов механического съёма и преобразования энергии до сих пор очень ограничено.
И вот эта четвёртая фаза, которую мы сегодня имеем на двух (на самом деле на большем числе) уровнях говорит о том, что эволюционный виток пройден. Это и имелось в виду под словами "замыкание генезиса фаз логики управления".
Появление трансформеров (GPT) позволяет человеку отдать им роль замыкающего звена и вставить их в техническую систему вместо себя. Машине гораздо сподручнее общаться с машиной, чем человеку.
Новизна этой сентенции не в том, что "машина заменит человека", а в формальной концепции, которая даёт ответы на вопросы, в чём заменит, почему, за счёт чего, когда, зачем и т.п. Т.е. позволяет снять истерию (которой сейчас реально очень много даже в научных кругах) и заняться конструктивной деятельностью.
Эволюция структур данных в языках программирования