Любой наш прогноз, тоже как бы в вероятностном поле. Скорее всего выгорит — действуем. Скорее всего провалится — ищем альтернативное, потенциально более успешное решение.
В целом — согласен. Но как вы хотите обучать действительно слепой, глухой и лишенный осязания "мозг в банке". Для начального набора эрудиции, существующий подход вполне рационален. Нерационально выжимать из него то, на что он изначально плохо приспособлен или не приспособлен вовсе.
Язык — инструмент описания реальности. Обучаться которой надо подобно школьникам. От простого к сложному. Параграф за параграфом, тему за темой, курс за курсом, предмет за предметом. Так, чтобы для обучения этому курсу, нужны были не гигабайты данных, а обычный учебник. На основании которого строить дистиллированный промежуточный слой графа понятий/сущностей, описывающий некий фрагмент реальности и уже на нем обучаться модели v.2.0.
Существующие модели, после соответствующего тюнинга, должны помочь в построении таких графов. А тюнингованные немного по другому, помогать тестерам искать слабые места. И так до тех пор, пока не удастся перейти на полное использование новой модели. Как при разработке компилятора, написать компилятор на том языке, который он компилирует.
Зачем-то опять выставляете так, будто я отрицаю полезность реактивности. Повторю, она полезна. Но как опциональный инструмент, а не фундаментальная концепция — ни шагу в сторону. Модель контролов, должна в равной удобной мере позволять использовать для них как реактивность, так и реализовать связи вручную через свойства/события.
Предположу, что мы уже оба в достаточной мере высказали свою позицию. На чем предлагаю попрощаться.
По нынешним временам слишком низкоуровнево. Как говорил выше, почти WinAPI. И даже если можно инкапсулировать, это надо делать самому. Поэтому не надо передергивать.
Возможно вы и правы. Но скорее потому, что мы говорим о разных интерфейсах. Для информационных страниц, просто добавь интерактивность, возможно существующие фреймворки годны. С другой стороны расположены полноценные десктопные приложения, в виде html-страницы (без рисования на canvas). Сплошь состоящие из контролов, контролов и еще раз контролов.
Как из моих слов вы сделали такой вывод? Хочу видеть UI контрол (скорее, хорошо проработанную библиотеку контролов), где вся сложность инкапсулирована и нужна, только если хочется чего-то эдакого, то есть в обычных условиях почти никогда. Он управляется собственными свойствами и событиями, в том числе с одно и двунаправленной привязкой к данным. Где ключевое "в том числе", а не исключительно.
Backbone, насколько про него когда-то читал, мог бы служить далеким предком такого подхода. А вот с jQuery даже рядом не лежало.
Хороший аргумент. :) Но разве к WPF реактивность прибита гвоздями? В свойство Text обычного TextBox можно записать одно и двунаправленные биндинги, а можно собственно текст. И это правильно. Где удобнее реактивность, используем реактивность. Где не удобнее, используем свойства и события UI контрола. Думаю на мобилах разработчик тоже не прибит гвоздями к парадигме.
Тут правда рядом на биндинги жаловались, но я наоборот, считаю это контролируемой сложностью.
Мышкой, кодом или декларативно аля QML, но да, что-то похожее.
Причем нужна не столько для формочки из 3 полей, сколько для возможности увидеть и сравнить две парадигмы. Фронтендеры не готовы выйти из зоны комфорта и не видят жизни за пределами реактивной "клетки". А точно ли ее там нет? Почему за столько лет десктопа, не появилось ни одного новомодного, самого лучшего, изначально и до самого конца реактивного фреймворка? Уж точно дело не в простоте отображения изменения состояния окна, в противовес сложности модификации DOM. Реактивность вообще лежит вне этой аргументации. Это просто двунаправленная связь данных и контрола отображения.
Мои тезисы ничуть не противоречат вашим. Я не говорю что реактивность плоха, лишь что она — полезный инструмент, а не основополагающая базовая концепция, вокруг которой вертится всё-всё-всё. Должна быть сверху, предоставлять выбор использовать только там где нужна, а не снизу, вынуждая подстраиваться под себя везде.
В принципе, никто не мешает реализовать часть самостоятельно. Но есть нюанс, нет ни одного императивного WebUI фреймворка. а самостоятельная реализация уходит в излишне низкоуровневый слой. А вот если бы был, возможно архитектура и взяла бы лучшее из обоих миров.
Вот про это и речь. Почему сразу реактивность? Свет клином сошелся? Десктоп испокон живет без нее, а интерфейсы многих программ, намного более функциональны. Также стоит посмотреть на классические интерфейсы мобильных iOS/Android приложений. При этом я не отрицаю полезности реактивности в отдельных местах.
Когда поглядываю на веб-фреймворки, вижу в них скорее не UI фреймворки, а брокера связности, на котором можно писать UI. Не настолько квалифицирован в данной области, чтобы продвигать настолько глобальные архитектурные концепции, однако хотелось бы видеть более глубокое разделение на собственно UI фреймворк и брокера. Первый позволяет писать UI и только за него отвечает. Причем UI виджеты должны быть более отдалены от их реализации, которую поймет браузер и более отражать сущность виджета. Второй отвечает за объект данных. А разработчик может выбрать, использовать классическую модель событий onCreate / onShow / onChange реализуя требуемое императивно или подключить данный виджет к отслеживаемой переменной декларативно. И даже сделать гибрид — пользовательские действия в виджете обрабатывать императивно, а изменения в данных отображать на виджет декларативно.
Возможно стоит обратиться внимание на GUI приложений. Тут конечно и про них немало "добрых" слов уже сказали. Однако создается впечатление, что все WebUI фрейморки, по своей сути ближе к этапу написания GUI на чистом WinAPI, чем к сколь-нибудь развитым GUI фреймворкам.
Мы кажется немного о разном. Впрочем поправлю свое утверждение — вероятность нарастания ошибки. И ошибки не уровне обработки языка (что это вообще такое?), а уровне рассуждений. Из этого следует это. Следствие становится достоверным (?) утверждением. Из этого следует это.
Языковые модели этого не умеют by design. Следствие будет иметь score меньше 1. А перемножение двух таких значений, первый*второй уровень, даст результат меньше, чем каждый множитель. Остается только гадать, когда в конкретной цепочке утверждений, итоговый score упадет ниже порога достоверности и точно ли модель его правильно рассчитала (здравствуй галлюцинации).
В комментариях уже пробегал анекдот про 1000 символов в минуту и получаемую чушь. А ведь в каждой шутке, есть доля правды. Можно снижать требования к качеству набора. Естественно соблюдая баланс с качеством результата.
Можно собрать типовые ошибки из тренажеров набора. Можно вспомнить про swipe метод набора на виртуальных клавиатурах. Сколько там лишних букв затрагивается, но получаем вменяемый результат. То есть можно прогнозировать как более вероятную коррекцию, замену символа на соседний. И достаточно будет ткнуть пальцем куда-то в ту степь. Эдакий псевдо-Т9, но символы сгруппированы не по алфавиту, а по размещению на ЙЦУКЕН. Наверняка есть и другие варианты упрощения ввода.
Естественно будут возникать коллизии. Которые уже разрешат БЯМ, исходя из контекста. А в случае с недостаточной достоверностью можно даже оставить вариативность|палиативность, что послужит триггером "обратить внимание" при перечитывании написанного. Ведь в отличии от пиш.машинки, ввод можно редактировать.
Археология, потому что не смогли переложить на матричное исчисление и отказались, посчитав альтернативу перспективнее. А она оказалась недостаточно масштабируемой и уперлась в тупик. Но суть не в типе изменений, а направлении движения — нужна более детерминированная модель реальности.
Решил как-то посмотреть, как модели видят слова. Разметил омоним/омограф "вертел", по полсотни вхождений на каждый класс. Взял несколько BERT-энкодеров. И уменьшил размерность до 2.
Все модели повели себя плюс-минус одинаково. Что-то заподозрили, но облако точек выглядело как начало процесса размножения делением у одноклеточных. Начали формироваться две группы, но с громадным их пересечением. И это для слова, принадлежащего к разным частям речи — существительное и глагол.
Также добавил два синонима, соответственно существительное и глагол — шампур и крутил. Их облака точек расположились, как и ожидалось после уменьшения размерности, довольно далеко друг от друга. А "вертел" притянулся заметно ближе к "крутил", как содержащий наиболее частотную форму "верте́л".
Но что же ожидалось? Одинаковые части речи должны были показать гораздо большую семантическую близость, чем близость между обоим их представителями — верте́л ближе к крутил и дальше от ве́ртел. В идеале иметь не облако "смыслов", а точку.
А ведь эти эмбединги лежат в основе языковых моделей. Поверх которых строится оценка фраз — последовательностей смыслов. Оцените как будет нарастать ошибка при построении связей второго порядка — сущность через сущность. Причем, считаю, что эмбединг не способен полностью отразить все связи сущности/термина с учетом их веса. Нужна более детерминированная древовидная/графовая модель реальности. Тогда и рассуждения перестанут накапливать ошибку.
Ну а пока надо помнить, что языковая модель ≠ модель реальности. Со всеми вытекающими.
Когда пишешь сверху вниз, можно хорошо прописать интерфейсы и типы. Но если снизу вверх, проект постепенно сшивается из кусков, сами интерфейсы видоизменяются во времени. Здесь была серия статей про использование Rust в геймдеве и возникающие проблемы упомянутого класса.
Не в упрек языку. Но очень редко плюсы бывают без сопровождающих минусов и соответственно наоборот.
Самое главное в оценке этого вопроса, воздержаться от ярлыков. Потому что тема вполне может быть урегулирована компромиссно. Компромисс означает, что каждый что-то получит, но не так, как хотел изначально.
Изначальная проблема, кмк, в однонаправленности отношений субъектов продавец/покупатель. Закрепленных законом и подтвержденных практиками. Вот тебе условия, или соглашаешься, или проходи мимо. В принципе это нормально. На каком-то низком уровне. Но чем значимее тема, чем больше ее контекст отличается от привычного ранее, тем больше к этому тезису вопросов. Государство вполне устанавливает цены/наценки на значимые товары или применяет антимонопольное законодательство. Юристы наверняка назовут еще десятки механизмов регулирования.
В случае информации, есть примеры саморегулирования до уровня win-win. Например gPlay с фактически микроплатежом за программу. "Автор.сегодня" неплохо модернизирует ситуацию с литературой. То есть внешние регулирующие механизмы, раз уж внутренние вызывают такие яркие конфликты, должны не запрещать что-либо, а приводить к компромиссу.
Не спорю с экспертами, но хочу заметить, что корректную экспертизу провести весьма непросто. Слишком часта ошибка несовпадения контекста ЧП и экспертизы — послезнание. Которая отлично показана в фильме Sully (Чудо на Гудзоне). Эксперимент должен проводится, когда эксперт не ожидает чрезвычайной ситуации и тем более не знает, что проверяет уже случившееся ЧП. То есть должен находится в состоянии обычного рабочего внимания и действовать строго по процедуре, с учетом времени на осознание ситуации и принятие решения. Каковое время, в постфактумной экспертизе обычно игнорируют.
Когда-то писал довольно развернутые приложения на Delphi. Десятки форм с разной степенью генерации содержимого по метаданным. Grid, list, edit, label собранные на Panel или саму форму. В том числе с получением и сохранением данных во внешних источниках — невидимый DataSet и визуальные компоненты с приставкой Data. Сложность была контролируемой. Понятной. Вменяемый цикл событий. При желании, вполне можно было реализовать реактивность. В нужном объеме.
Так может проблемы WebGUI в недостаточном уровне инкапсуляции? И безальтернативной реактивностью? Слишком близко к низам — html, css. Нет вменяемой объектной модели компонентов. И только один поток связывания, где надо и не надо.
Строки правильны с алгоритмической точки зрения, но это приносит некоторое количество боли. Во-первых многословны. Если код направлен на массовую работу со строками, читать тяжело. Во-вторых, не совпадает опыт с другими языками/реализациями. Ни в одном языке нет такого количества WTF при работе со строками у изучающих язык.
Резоны разработчиков языка о гарантиях производительности при работе со строками понятны. Индексация UTF вытащена в код. Но хотелось бы видеть в дополнение к существующему варианту, реализацию StringScalar (аналог видения строк в Питоне) и StringGrapheme, с которыми можно было работать именно как со строками (размер, срез, итерация и пр.). Где сложность обработки/индексации инкапсулирована, пусть и в ущерб производительности. Точнее в ущерб не производительности (она одинаковая), а в ущерб ожиданиям производительности.
Любой наш прогноз, тоже как бы в вероятностном поле. Скорее всего выгорит — действуем. Скорее всего провалится — ищем альтернативное, потенциально более успешное решение.
В целом — согласен. Но как вы хотите обучать действительно слепой, глухой и лишенный осязания "мозг в банке". Для начального набора эрудиции, существующий подход вполне рационален. Нерационально выжимать из него то, на что он изначально плохо приспособлен или не приспособлен вовсе.
Язык — инструмент описания реальности. Обучаться которой надо подобно школьникам. От простого к сложному. Параграф за параграфом, тему за темой, курс за курсом, предмет за предметом. Так, чтобы для обучения этому курсу, нужны были не гигабайты данных, а обычный учебник. На основании которого строить дистиллированный промежуточный слой графа понятий/сущностей, описывающий некий фрагмент реальности и уже на нем обучаться модели v.2.0.
Существующие модели, после соответствующего тюнинга, должны помочь в построении таких графов. А тюнингованные немного по другому, помогать тестерам искать слабые места. И так до тех пор, пока не удастся перейти на полное использование новой модели. Как при разработке компилятора, написать компилятор на том языке, который он компилирует.
Зачем-то опять выставляете так, будто я отрицаю полезность реактивности. Повторю, она полезна. Но как опциональный инструмент, а не фундаментальная концепция — ни шагу в сторону. Модель контролов, должна в равной удобной мере позволять использовать для них как реактивность, так и реализовать связи вручную через свойства/события.
Предположу, что мы уже оба в достаточной мере высказали свою позицию. На чем предлагаю попрощаться.
По нынешним временам слишком низкоуровнево. Как говорил выше, почти WinAPI. И даже если можно инкапсулировать, это надо делать самому. Поэтому не надо передергивать.
Возможно вы и правы. Но скорее потому, что мы говорим о разных интерфейсах. Для информационных страниц, просто добавь интерактивность, возможно существующие фреймворки годны. С другой стороны расположены полноценные десктопные приложения, в виде html-страницы (без рисования на canvas). Сплошь состоящие из контролов, контролов и еще раз контролов.
Как из моих слов вы сделали такой вывод? Хочу видеть UI контрол (скорее, хорошо проработанную библиотеку контролов), где вся сложность инкапсулирована и нужна, только если хочется чего-то эдакого, то есть в обычных условиях почти никогда. Он управляется собственными свойствами и событиями, в том числе с одно и двунаправленной привязкой к данным. Где ключевое "в том числе", а не исключительно.
Backbone, насколько про него когда-то читал, мог бы служить далеким предком такого подхода. А вот с jQuery даже рядом не лежало.
Хороший аргумент. :) Но разве к WPF реактивность прибита гвоздями? В свойство Text обычного TextBox можно записать одно и двунаправленные биндинги, а можно собственно текст. И это правильно. Где удобнее реактивность, используем реактивность. Где не удобнее, используем свойства и события UI контрола. Думаю на мобилах разработчик тоже не прибит гвоздями к парадигме.
Тут правда рядом на биндинги жаловались, но я наоборот, считаю это контролируемой сложностью.
Мышкой, кодом или декларативно аля QML, но да, что-то похожее.
Причем нужна не столько для формочки из 3 полей, сколько для возможности увидеть и сравнить две парадигмы. Фронтендеры не готовы выйти из зоны комфорта и не видят жизни за пределами реактивной "клетки". А точно ли ее там нет? Почему за столько лет десктопа, не появилось ни одного новомодного, самого лучшего, изначально и до самого конца реактивного фреймворка? Уж точно дело не в простоте отображения изменения состояния окна, в противовес сложности модификации DOM. Реактивность вообще лежит вне этой аргументации. Это просто двунаправленная связь данных и контрола отображения.
Мои тезисы ничуть не противоречат вашим. Я не говорю что реактивность плоха, лишь что она — полезный инструмент, а не основополагающая базовая концепция, вокруг которой вертится всё-всё-всё. Должна быть сверху, предоставлять выбор использовать только там где нужна, а не снизу, вынуждая подстраиваться под себя везде.
В принципе, никто не мешает реализовать часть самостоятельно. Но есть нюанс, нет ни одного императивного WebUI фреймворка. а самостоятельная реализация уходит в излишне низкоуровневый слой. А вот если бы был, возможно архитектура и взяла бы лучшее из обоих миров.
Вот про это и речь. Почему сразу реактивность? Свет клином сошелся? Десктоп испокон живет без нее, а интерфейсы многих программ, намного более функциональны. Также стоит посмотреть на классические интерфейсы мобильных iOS/Android приложений. При этом я не отрицаю полезности реактивности в отдельных местах.
Когда поглядываю на веб-фреймворки, вижу в них скорее не UI фреймворки, а брокера связности, на котором можно писать UI. Не настолько квалифицирован в данной области, чтобы продвигать настолько глобальные архитектурные концепции, однако хотелось бы видеть более глубокое разделение на собственно UI фреймворк и брокера. Первый позволяет писать UI и только за него отвечает. Причем UI виджеты должны быть более отдалены от их реализации, которую поймет браузер и более отражать сущность виджета. Второй отвечает за объект данных. А разработчик может выбрать, использовать классическую модель событий onCreate / onShow / onChange реализуя требуемое императивно или подключить данный виджет к отслеживаемой переменной декларативно. И даже сделать гибрид — пользовательские действия в виджете обрабатывать императивно, а изменения в данных отображать на виджет декларативно.
Возможно стоит обратиться внимание на GUI приложений. Тут конечно и про них немало "добрых" слов уже сказали. Однако создается впечатление, что все WebUI фрейморки, по своей сути ближе к этапу написания GUI на чистом WinAPI, чем к сколь-нибудь развитым GUI фреймворкам.
Мы кажется немного о разном. Впрочем поправлю свое утверждение — вероятность нарастания ошибки. И ошибки не уровне обработки языка (что это вообще такое?), а уровне рассуждений. Из этого следует это. Следствие становится достоверным (?) утверждением. Из этого следует это.
Языковые модели этого не умеют by design. Следствие будет иметь score меньше 1. А перемножение двух таких значений, первый*второй уровень, даст результат меньше, чем каждый множитель. Остается только гадать, когда в конкретной цепочке утверждений, итоговый score упадет ниже порога достоверности и точно ли модель его правильно рассчитала (здравствуй галлюцинации).
В комментариях уже пробегал анекдот про 1000 символов в минуту и получаемую чушь. А ведь в каждой шутке, есть доля правды. Можно снижать требования к качеству набора. Естественно соблюдая баланс с качеством результата.
Можно собрать типовые ошибки из тренажеров набора. Можно вспомнить про swipe метод набора на виртуальных клавиатурах. Сколько там лишних букв затрагивается, но получаем вменяемый результат. То есть можно прогнозировать как более вероятную коррекцию, замену символа на соседний. И достаточно будет ткнуть пальцем куда-то в ту степь. Эдакий псевдо-Т9, но символы сгруппированы не по алфавиту, а по размещению на ЙЦУКЕН. Наверняка есть и другие варианты упрощения ввода.
Естественно будут возникать коллизии. Которые уже разрешат БЯМ, исходя из контекста. А в случае с недостаточной достоверностью можно даже оставить вариативность|палиативность, что послужит триггером "обратить внимание" при перечитывании написанного. Ведь в отличии от пиш.машинки, ввод можно редактировать.
Археология, потому что не смогли переложить на матричное исчисление и отказались, посчитав альтернативу перспективнее. А она оказалась недостаточно масштабируемой и уперлась в тупик. Но суть не в типе изменений, а направлении движения — нужна более детерминированная модель реальности.
Решил как-то посмотреть, как модели видят слова. Разметил омоним/омограф "вертел", по полсотни вхождений на каждый класс. Взял несколько BERT-энкодеров. И уменьшил размерность до 2.
Все модели повели себя плюс-минус одинаково. Что-то заподозрили, но облако точек выглядело как начало процесса размножения делением у одноклеточных. Начали формироваться две группы, но с громадным их пересечением. И это для слова, принадлежащего к разным частям речи — существительное и глагол.
Также добавил два синонима, соответственно существительное и глагол — шампур и крутил. Их облака точек расположились, как и ожидалось после уменьшения размерности, довольно далеко друг от друга. А "вертел" притянулся заметно ближе к "крутил", как содержащий наиболее частотную форму "верте́л".
Но что же ожидалось? Одинаковые части речи должны были показать гораздо большую семантическую близость, чем близость между обоим их представителями — верте́л ближе к крутил и дальше от ве́ртел. В идеале иметь не облако "смыслов", а точку.
А ведь эти эмбединги лежат в основе языковых моделей. Поверх которых строится оценка фраз — последовательностей смыслов. Оцените как будет нарастать ошибка при построении связей второго порядка — сущность через сущность. Причем, считаю, что эмбединг не способен полностью отразить все связи сущности/термина с учетом их веса. Нужна более детерминированная древовидная/графовая модель реальности. Тогда и рассуждения перестанут накапливать ошибку.
Ну а пока надо помнить, что языковая модель ≠ модель реальности. Со всеми вытекающими.
Разве при очистке регулярка '\W+' не заменит пунктуацию на пробелы? Чем поломает и/или сделает ненужной всю следующую обработку.
Беря только первую форму из PyMorphy, прощай омонимы. У слова может быть несколько нормальных форм и частей речи.
Когда пишешь сверху вниз, можно хорошо прописать интерфейсы и типы. Но если снизу вверх, проект постепенно сшивается из кусков, сами интерфейсы видоизменяются во времени. Здесь была серия статей про использование Rust в геймдеве и возникающие проблемы упомянутого класса.
Не в упрек языку. Но очень редко плюсы бывают без сопровождающих минусов и соответственно наоборот.
Самое главное в оценке этого вопроса, воздержаться от ярлыков. Потому что тема вполне может быть урегулирована компромиссно. Компромисс означает, что каждый что-то получит, но не так, как хотел изначально.
Изначальная проблема, кмк, в однонаправленности отношений субъектов продавец/покупатель. Закрепленных законом и подтвержденных практиками. Вот тебе условия, или соглашаешься, или проходи мимо. В принципе это нормально. На каком-то низком уровне. Но чем значимее тема, чем больше ее контекст отличается от привычного ранее, тем больше к этому тезису вопросов. Государство вполне устанавливает цены/наценки на значимые товары или применяет антимонопольное законодательство. Юристы наверняка назовут еще десятки механизмов регулирования.
В случае информации, есть примеры саморегулирования до уровня win-win. Например gPlay с фактически микроплатежом за программу. "Автор.сегодня" неплохо модернизирует ситуацию с литературой. То есть внешние регулирующие механизмы, раз уж внутренние вызывают такие яркие конфликты, должны не запрещать что-либо, а приводить к компромиссу.
Не спорю с экспертами, но хочу заметить, что корректную экспертизу провести весьма непросто. Слишком часта ошибка несовпадения контекста ЧП и экспертизы — послезнание. Которая отлично показана в фильме Sully (Чудо на Гудзоне). Эксперимент должен проводится, когда эксперт не ожидает чрезвычайной ситуации и тем более не знает, что проверяет уже случившееся ЧП. То есть должен находится в состоянии обычного рабочего внимания и действовать строго по процедуре, с учетом времени на осознание ситуации и принятие решения. Каковое время, в постфактумной экспертизе обычно игнорируют.
Когда-то писал довольно развернутые приложения на Delphi. Десятки форм с разной степенью генерации содержимого по метаданным. Grid, list, edit, label собранные на Panel или саму форму. В том числе с получением и сохранением данных во внешних источниках — невидимый DataSet и визуальные компоненты с приставкой Data. Сложность была контролируемой. Понятной. Вменяемый цикл событий. При желании, вполне можно было реализовать реактивность. В нужном объеме.
Так может проблемы WebGUI в недостаточном уровне инкапсуляции? И безальтернативной реактивностью? Слишком близко к низам — html, css. Нет вменяемой объектной модели компонентов. И только один поток связывания, где надо и не надо.
Строки правильны с алгоритмической точки зрения, но это приносит некоторое количество боли. Во-первых многословны. Если код направлен на массовую работу со строками, читать тяжело. Во-вторых, не совпадает опыт с другими языками/реализациями. Ни в одном языке нет такого количества WTF при работе со строками у изучающих язык.
Резоны разработчиков языка о гарантиях производительности при работе со строками понятны. Индексация UTF вытащена в код. Но хотелось бы видеть в дополнение к существующему варианту, реализацию StringScalar (аналог видения строк в Питоне) и StringGrapheme, с которыми можно было работать именно как со строками (размер, срез, итерация и пр.). Где сложность обработки/индексации инкапсулирована, пусть и в ущерб производительности. Точнее в ущерб не производительности (она одинаковая), а в ущерб ожиданиям производительности.