Сообщение Re[6]: JSON vs BSON: очередное торжество больного воображени от 03.12.2022 16:20
Изменено 03.12.2022 17:27 vdimas
Re[6]: JSON vs BSON: очередное торжество больного воображени
Здравствуйте, Baiker, Вы писали:
B>В этом и проблема — твоя убогость суждений говорит о том, что ты ничего, кроме как "валидная структура ЯП" не видишь. JSON был сделан намного универсальнее — ему вообще не нужно опираться на синтаксис ЛЮБОГО из языков!
Я именно это и сказал.
И именно оно является причиной убожества JSON для 99.9% реальных сценариев.
B>Хочешь — напиши проперть так:
B> "Some strange @ property": 3.1415
А с этим кто-то спорит?
Для 0.1% сценариев, типа твоего примера, JSON подходит идеально.
B>В JSON может и можно что-то подсократить (к примеру, escape-последовательности), но в целом формат оптимален. Надо просто думать чуть абстрактнее.
Надо просто не забывать основные правила инженерии в пылу спора. ))
V>>Each object can be given a special unique property called an id
B>И шо? Потом бегать по сорсам и панически проверять, нет ли В ТВОЁМ коде поля id, чтобы не пересечься с QML?
Внимательней надо быть — чтобы пересечься с QML, надо оперировать не значениями, а идентификаторами.
V>>В общем, JSON хорош там, где он служит чем-то вроде сокета для обмена с третьесторонним окружением.
V>>А так-то хрень полная.
B>Это твоё утверждение — хрень полная. JSON прекрасно себя показал независимо от сторон, куда/откуда он передаётся.
Л — логика.
Любая избыточная хрень покрывает сценарии, где она избыточна.
V>>В общем по-классике — самое общее решение является самым худшим для конкретного случая.
B>В корне неверно.
Одно из основных правил инженерии "в корне неверно"? (С)
Забавное пошло поколение next.
Что мешало ввести в JSON "уровни", "слои", "диалекты", чтобы общающиеся по протоколу JSON counterparty могли специфировать этот уровень/диалект?
Т.е., чтобы спецификацией шёл не просто JSON, а некие JSON-base, JSON-optimized, JSON-optimized-referenced, где каждый следующий уровень без проблем бы парсил описание более младшего уровня?
Решения такого рода вполне обычны для инженерии, но в случае JSON приняты не были.
Почему? — из-за истории развития JSON, из-за уровня подготовки тех людей, которые изначально толкали этот формат.
Сначала это был просто валидный JS в той части синтаксиса, где описывается структура объектов.
Затем эту часть выделили в отдельную спецификацию, чтобы не исполнять атакующий хакерский JS-код в этом описании, т.е. слабость такого подхода всплыла сразу — примерно понятно, какого пошиба люди пользовали этой техникой.
ОК, выделили сугубо описательную часть "наколенным" образом.
Т.е. изначальная идея "ничего не делать", типа чтобы описания JS-объектов "подхватывались сами" вынужденно трансформировалась до задачи "написать отдельный парсер".
Так шта, как ни крути, но JSON не был разработан как обычно разрабатываются стандарты языков структурированных описаний, он вырос сугубо из наколенных экспериментов.
B>"Конкретный случай" может прекрасно ложиться под "общее решение". Достаточно посмотреть, как JSON реализован в целом множестве ЯП — буквально "однострочная" {де}сериализация даёт возможность ВО ВСЕХ(!) языках вообще не париться, что там за JSON приехал. Это и есть доказательство универсальности формата — он прекрасно лёг подо все языки, что никому не пришлось "корёжить" оригинальный формат.
Это лишь доказательство убогости.
Ну какая хрен разница, в 10 строк парсер или в 100?
Эффективность LL(1)-парсера от этого не зависит, она зависит только от выразительности грамматики.
И чем выразительней грамматика, тем эффективнее парсер, по ней работающий.
Это тоже азы.
Тут причина тупизны в другом — для наколенных разработчиков первых реализаций JSON термины навроде "LL(1)-парсер" — что-то вроде страшного ругательства, бгг...
Его придумали веб-кодеры для передачи данных вместо принятого ранее XML.
Кстате, я загнул про LR(1) парсер в прошлом сообщении, он нужен только если на парсер не работает предварительно токенайзер-лексер.
С выделенным токенайзером там, действительно, совсем на единицы строчек наколенного LL(1)-парсера, причём в любом из описанных гипотетических "уровней".
То бишь, твой аргумент про "наколенность" не сыграл — там будет простейшая реализация для любого предложенного уровня поддержки JS-подобного синтаксиса.
B>В этом и проблема — твоя убогость суждений говорит о том, что ты ничего, кроме как "валидная структура ЯП" не видишь. JSON был сделан намного универсальнее — ему вообще не нужно опираться на синтаксис ЛЮБОГО из языков!
Я именно это и сказал.
И именно оно является причиной убожества JSON для 99.9% реальных сценариев.
B>Хочешь — напиши проперть так:
B> "Some strange @ property": 3.1415
А с этим кто-то спорит?
Для 0.1% сценариев, типа твоего примера, JSON подходит идеально.
B>В JSON может и можно что-то подсократить (к примеру, escape-последовательности), но в целом формат оптимален. Надо просто думать чуть абстрактнее.
Надо просто не забывать основные правила инженерии в пылу спора. ))
V>>Each object can be given a special unique property called an id
B>И шо? Потом бегать по сорсам и панически проверять, нет ли В ТВОЁМ коде поля id, чтобы не пересечься с QML?
Внимательней надо быть — чтобы пересечься с QML, надо оперировать не значениями, а идентификаторами.
V>>В общем, JSON хорош там, где он служит чем-то вроде сокета для обмена с третьесторонним окружением.
V>>А так-то хрень полная.
B>Это твоё утверждение — хрень полная. JSON прекрасно себя показал независимо от сторон, куда/откуда он передаётся.
Л — логика.
Любая избыточная хрень покрывает сценарии, где она избыточна.
V>>В общем по-классике — самое общее решение является самым худшим для конкретного случая.
B>В корне неверно.
Одно из основных правил инженерии "в корне неверно"? (С)
Забавное пошло поколение next.
Что мешало ввести в JSON "уровни", "слои", "диалекты", чтобы общающиеся по протоколу JSON counterparty могли специфировать этот уровень/диалект?
Т.е., чтобы спецификацией шёл не просто JSON, а некие JSON-base, JSON-optimized, JSON-optimized-referenced, где каждый следующий уровень без проблем бы парсил описание более младшего уровня?
Решения такого рода вполне обычны для инженерии, но в случае JSON приняты не были.
Почему? — из-за истории развития JSON, из-за уровня подготовки тех людей, которые изначально толкали этот формат.
Сначала это был просто валидный JS в той части синтаксиса, где описывается структура объектов.
Затем эту часть выделили в отдельную спецификацию, чтобы не исполнять атакующий хакерский JS-код в этом описании, т.е. слабость такого подхода всплыла сразу — примерно понятно, какого пошиба люди пользовали этой техникой.
ОК, выделили сугубо описательную часть "наколенным" образом.
Т.е. изначальная идея "ничего не делать", типа чтобы описания JS-объектов "подхватывались сами" вынужденно трансформировалась до задачи "написать отдельный парсер".
Так шта, как ни крути, но JSON не был разработан как обычно разрабатываются стандарты языков структурированных описаний, он вырос сугубо из наколенных экспериментов.
B>"Конкретный случай" может прекрасно ложиться под "общее решение". Достаточно посмотреть, как JSON реализован в целом множестве ЯП — буквально "однострочная" {де}сериализация даёт возможность ВО ВСЕХ(!) языках вообще не париться, что там за JSON приехал. Это и есть доказательство универсальности формата — он прекрасно лёг подо все языки, что никому не пришлось "корёжить" оригинальный формат.
Это лишь доказательство убогости.
Ну какая хрен разница, в 10 строк парсер или в 100?
Эффективность LL(1)-парсера от этого не зависит, она зависит только от выразительности грамматики.
И чем выразительней грамматика, тем эффективнее парсер, по ней работающий.
Это тоже азы.
Тут причина тупизны в другом — для наколенных разработчиков первых реализаций JSON термины навроде "LL(1)-парсер" — что-то вроде страшного ругательства, бгг...
Его придумали веб-кодеры для передачи данных вместо принятого ранее XML.
Кстате, я загнул про LR(1) парсер в прошлом сообщении, он нужен только если на парсер не работает предварительно токенайзер-лексер.
С выделенным токенайзером там, действительно, совсем на единицы строчек наколенного LL(1)-парсера, причём в любом из описанных гипотетических "уровней".
То бишь, твой аргумент про "наколенность" не сыграл — там будет простейшая реализация для любого предложенного уровня поддержки JS-подобного синтаксиса.
Re[6]: JSON vs BSON: очередное торжество больного воображени
Здравствуйте, Baiker, Вы писали:
B>В этом и проблема — твоя убогость суждений говорит о том, что ты ничего, кроме как "валидная структура ЯП" не видишь. JSON был сделан намного универсальнее — ему вообще не нужно опираться на синтаксис ЛЮБОГО из языков!
Я именно это и сказал.
И именно оно является причиной убожества JSON для 99.9% реальных сценариев.
B>Хочешь — напиши проперть так:
B> "Some strange @ property": 3.1415
А с этим кто-то спорит?
Для 0.1% сценариев, типа твоего примера, JSON подходит идеально.
B>В JSON может и можно что-то подсократить (к примеру, escape-последовательности), но в целом формат оптимален. Надо просто думать чуть абстрактнее.
Надо просто не забывать основные правила инженерии в пылу спора. ))
V>>Each object can be given a special unique property called an id
B>И шо? Потом бегать по сорсам и панически проверять, нет ли В ТВОЁМ коде поля id, чтобы не пересечься с QML?
Внимательней надо быть — чтобы пересечься с QML, надо оперировать не значениями, а идентификаторами.
V>>В общем, JSON хорош там, где он служит чем-то вроде сокета для обмена с третьесторонним окружением.
V>>А так-то хрень полная.
B>Это твоё утверждение — хрень полная. JSON прекрасно себя показал независимо от сторон, куда/откуда он передаётся.
Л — логика.
Любая избыточная хрень покрывает сценарии, где она избыточна.
V>>В общем по-классике — самое общее решение является самым худшим для конкретного случая.
B>В корне неверно.
Одно из основных правил инженерии "в корне неверно"? (С)
Забавное пошло поколение next.
Что мешало ввести в JSON "уровни", "слои", "диалекты", чтобы общающиеся по протоколу JSON counterparty могли специфировать этот уровень/диалект?
Т.е., чтобы спецификацией шёл не просто JSON, а некие JSON-base, JSON-optimized, JSON-optimized-referenced, где каждый следующий уровень без проблем бы парсил описание более младшего уровня?
Решения такого рода вполне обычны для инженерии, но в случае JSON приняты не были.
Почему? — из-за истории развития JSON, из-за уровня подготовки тех людей, которые изначально толкали этот формат.
Сначала это был просто валидный JS в той части синтаксиса, где описывается структура объектов.
Затем эту часть выделили в отдельную спецификацию, чтобы не исполнять атакующий хакерский JS-код в этом описании, т.е. слабость такого подхода всплыла сразу — примерно понятно, какого пошиба люди пользовались этой техникой.
ОК, выделили сугубо описательную часть "наколенным" образом.
Т.е. изначальная идея "ничего не делать", типа чтобы описания JS-объектов "подхватывались сами" вынужденно трансформировалась до задачи "написать отдельный парсер".
Так шта, как ни крути, но JSON не был разработан как обычно разрабатываются стандарты языков структурированных описаний, он вырос сугубо из наколенных экспериментов.
B>"Конкретный случай" может прекрасно ложиться под "общее решение". Достаточно посмотреть, как JSON реализован в целом множестве ЯП — буквально "однострочная" {де}сериализация даёт возможность ВО ВСЕХ(!) языках вообще не париться, что там за JSON приехал. Это и есть доказательство универсальности формата — он прекрасно лёг подо все языки, что никому не пришлось "корёжить" оригинальный формат.
Это лишь доказательство убогости.
Ну какая хрен разница, в 10 строк парсер или в 100?
Эффективность LL(1)-парсера от этого не зависит, она зависит только от выразительности грамматики.
И чем выразительней грамматика, тем эффективнее парсер, по ней работающий.
Это тоже азы.
Тут причина тупизны в другом — для наколенных разработчиков первых реализаций JSON термины навроде "LL(1)-парсер" — что-то вроде страшного ругательства, бгг...
Его придумали веб-кодеры для передачи данных вместо принятого ранее XML.
Кстате, я загнул про LR(1) парсер в прошлом сообщении, он нужен только если на парсер не работает предварительно токенайзер-лексер.
С выделенным токенайзером там, действительно, совсем на единицы строчек наколенного LL(1)-парсера, причём в любом из описанных гипотетических "уровней".
То бишь, твой аргумент про "наколенность" не сыграл — там будет простейшая реализация для любого предложенного уровня поддержки JS-подобного синтаксиса.
B>В этом и проблема — твоя убогость суждений говорит о том, что ты ничего, кроме как "валидная структура ЯП" не видишь. JSON был сделан намного универсальнее — ему вообще не нужно опираться на синтаксис ЛЮБОГО из языков!
Я именно это и сказал.
И именно оно является причиной убожества JSON для 99.9% реальных сценариев.
B>Хочешь — напиши проперть так:
B> "Some strange @ property": 3.1415
А с этим кто-то спорит?
Для 0.1% сценариев, типа твоего примера, JSON подходит идеально.
B>В JSON может и можно что-то подсократить (к примеру, escape-последовательности), но в целом формат оптимален. Надо просто думать чуть абстрактнее.
Надо просто не забывать основные правила инженерии в пылу спора. ))
V>>Each object can be given a special unique property called an id
B>И шо? Потом бегать по сорсам и панически проверять, нет ли В ТВОЁМ коде поля id, чтобы не пересечься с QML?
Внимательней надо быть — чтобы пересечься с QML, надо оперировать не значениями, а идентификаторами.
V>>В общем, JSON хорош там, где он служит чем-то вроде сокета для обмена с третьесторонним окружением.
V>>А так-то хрень полная.
B>Это твоё утверждение — хрень полная. JSON прекрасно себя показал независимо от сторон, куда/откуда он передаётся.
Л — логика.
Любая избыточная хрень покрывает сценарии, где она избыточна.
V>>В общем по-классике — самое общее решение является самым худшим для конкретного случая.
B>В корне неверно.
Одно из основных правил инженерии "в корне неверно"? (С)
Забавное пошло поколение next.
Что мешало ввести в JSON "уровни", "слои", "диалекты", чтобы общающиеся по протоколу JSON counterparty могли специфировать этот уровень/диалект?
Т.е., чтобы спецификацией шёл не просто JSON, а некие JSON-base, JSON-optimized, JSON-optimized-referenced, где каждый следующий уровень без проблем бы парсил описание более младшего уровня?
Решения такого рода вполне обычны для инженерии, но в случае JSON приняты не были.
Почему? — из-за истории развития JSON, из-за уровня подготовки тех людей, которые изначально толкали этот формат.
Сначала это был просто валидный JS в той части синтаксиса, где описывается структура объектов.
Затем эту часть выделили в отдельную спецификацию, чтобы не исполнять атакующий хакерский JS-код в этом описании, т.е. слабость такого подхода всплыла сразу — примерно понятно, какого пошиба люди пользовались этой техникой.
ОК, выделили сугубо описательную часть "наколенным" образом.
Т.е. изначальная идея "ничего не делать", типа чтобы описания JS-объектов "подхватывались сами" вынужденно трансформировалась до задачи "написать отдельный парсер".
Так шта, как ни крути, но JSON не был разработан как обычно разрабатываются стандарты языков структурированных описаний, он вырос сугубо из наколенных экспериментов.
B>"Конкретный случай" может прекрасно ложиться под "общее решение". Достаточно посмотреть, как JSON реализован в целом множестве ЯП — буквально "однострочная" {де}сериализация даёт возможность ВО ВСЕХ(!) языках вообще не париться, что там за JSON приехал. Это и есть доказательство универсальности формата — он прекрасно лёг подо все языки, что никому не пришлось "корёжить" оригинальный формат.
Это лишь доказательство убогости.
Ну какая хрен разница, в 10 строк парсер или в 100?
Эффективность LL(1)-парсера от этого не зависит, она зависит только от выразительности грамматики.
И чем выразительней грамматика, тем эффективнее парсер, по ней работающий.
Это тоже азы.
Тут причина тупизны в другом — для наколенных разработчиков первых реализаций JSON термины навроде "LL(1)-парсер" — что-то вроде страшного ругательства, бгг...
Его придумали веб-кодеры для передачи данных вместо принятого ранее XML.
Кстате, я загнул про LR(1) парсер в прошлом сообщении, он нужен только если на парсер не работает предварительно токенайзер-лексер.
С выделенным токенайзером там, действительно, совсем на единицы строчек наколенного LL(1)-парсера, причём в любом из описанных гипотетических "уровней".
То бишь, твой аргумент про "наколенность" не сыграл — там будет простейшая реализация для любого предложенного уровня поддержки JS-подобного синтаксиса.