Здравствуйте, Sinix, Вы писали:

A>>Это всего лишь проблема реализации.
S>Перевожу с маркетингового на человеческий: "валидный" json может: — Прочитаться нормально — Не прочитаться вообще- Прочитаться, но с комментариями вместо значений.
S>Ну и смысл играть в продакшне в русскую рулетку?

Здесь неуместно говорить о случайности. В конкретном проекте мы точно знаем, что может тот или иной использованный нами инструмент. Мы ж не читаем, к примеру, конфигурационные файлы чем попало, всегда используется конкретная выбранная нами или нами написанная реализация.

Здравствуйте, andrey82, Вы писали:

A>Здравствуйте, Sinix, Вы писали:

S>>Хипстеры, сэр.
S>>Если серьёзно, то большинство людей руками туда лезть будут не чаще, чем в нынешний xml. Какая разница?

A>А аналоги XSD (для того же intellisense нужно вроде) и XSLT (хочу например html справку из XML .config файла делать) для json уже существуют? Или оно не надо?

Не просто есть, а в том же project.json он не только структуру проверяет, но и имена пакетов и их версии при вводе тоже. То же самое для package.json (npm) и bower.json (bower).

Здравствуйте, Нахлобуч, Вы писали:

Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?
Это очень умные, но очень ленивые люди.

Пока многие возились в Visual Studio\Eclipse\NetBeans и подобных комбайнах вырос совершенно другой мир — работающий на Nodejs, включающий в себя пакетные менеджеры npm и bower, системы сборки gulp и grunt, и редакторы типа atom. Так как большая часть всего этого добра работала на js, то json стал форматом по умолчанию. XML по сравнению с ним вылгядит как плохая шутка, его нечем парсить в JS, а закрывать теги вручную или править названия (без поддержки IDE) — аццкий геморрой.

Умные люди посмотрели на эту картину и поняли, что нефиг изобретать свою песочницу, надо сделать аналогично тому что есть, потому что миллионы пишут на js и используют node в том или ином виде. Со временем и MS подоспел: сделали VS Code взяв за основу atom, слизали архитектуру ASP.NET 5 c Node-based стека, скопировав все подходы вплоть до JSON.

Человеку будет удобнее иметь bower.json и project.json, а не bower.json и project.xml. А тот же grunt\gulp вполне может прочитать project.json и использовать параметры из него при сборке.

Здравствуйте, anonymous, Вы писали:

a> A>>Это всего лишь проблема реализации.

a> S>Перевожу с маркетингового на человеческий: "валидный" json может: — Прочитаться нормально — Не прочитаться вообще- Прочитаться, но с комментариями вместо значений.
a> S>Ну и смысл играть в продакшне в русскую рулетку?

a> Здесь неуместно говорить о случайности. В конкретном проекте мы точно знаем, что может тот или иной использованный нами инструмент. Мы ж не читаем, к примеру, конфигурационные файлы чем попало, всегда используется конкретная выбранная нами или нами написанная реализация.

И вот в версии 2.31.23 выбранного решения наконец-то кардинально улучшили скорость работы(которая очень важна в проекте), но поменяли "правила" парсинга(потому как нет общепринятой спецификации/на нее все клали) и теперь нет гарантии что ключи прочитаются в нужном порядке. Что будем делать? Форк? Остаться на старой версии? Перейти на новую версию с прекращением поддержки коментариев?

DA>а в чём проблема редактирвоания XML в FARе?
В том же, в чем и в любом другом редакторе — не удобно, особенно, если файлик большой. у меня есть конфиг ~18000 строк, вложений > 10, править надо часто и в разных местах — задалбывает.

Здравствуйте, Нахлобуч, Вы писали:

Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?

Json сейчас будет теснить xml по причине все большей и большей популярности js и web api, к тому xml избыточнее json'a — это факт.
Xml связан все-таки более с rpc, wcf и soap — более страшными, тяжеловесными и старыми технологиями, поэтому МС скорее всего захотела быть в тренде и отходить от xml в сторону json.
Сейчас только самый ленивый не перешел на Web API с WCF & SOAP, так что все течет, все меняется и это хорошо

Здравствуйте, Нахлобуч, Вы писали:

Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?
Нормальные люди, которых достал XML.

В JSON гениально то, что он сериализуется в фундаментальные структуры данных: строку, число, карту и список. С единственной кодировкой — UTF-8.

И так как JSON примитивен донельзя, то его легко каноникализировать для криптографических целей (фактически, достаточно убрать pretty printing), тогда как канонический XML в общем случае до сих пор нормально не допилили: http://www.w3.org/standards/techs/xmlc14n#w3c_all

В то время, как XML — это нечто непонятно-всемогущее.

<xml>
  <a>Hello</a>
  <b>World!</b>
  <a>И снова, здравствуйте!</a>
</xml>

В XML — вполне нормальная ситуация. Ни на что разумное это не отображается (даже мультикарты не спасут). Так что с XML работа ведётся через абсолютно жуткий DOM API.

Но это ещё не всё! В XML есть namespace'ы, entities (которые могут утягивать данные из внешних источников) и поддержка кодировок. Это всё усложняет парсеры и код, работающий с их результатом.

Да, в XML есть удобная вещь — XSD-схемы для валидации. Но для JSON они тоже уже постепенно делаются (JSON Schema, JSON Relax и т.д.).

Единственное, что РЕАЛЬНО не хватает — это стандартные комментарии.

Здравствуйте, Dziman, Вы писали:

a>> Здесь неуместно говорить о случайности. В конкретном проекте мы точно знаем, что может тот или иной использованный нами инструмент. Мы ж не читаем, к примеру, конфигурационные файлы чем попало, всегда используется конкретная выбранная нами или нами написанная реализация.
D>И вот в версии 2.31.23 выбранного решения наконец-то кардинально улучшили скорость работы(которая очень важна в проекте), но поменяли "правила" парсинга(потому как нет общепринятой спецификации/на нее все клали) и теперь нет гарантии что ключи прочитаются в нужном порядке. Что будем делать? Форк? Остаться на старой версии? Перейти на новую версию с прекращением поддержки коментариев?

Для чего мы сейчас будем обсуждать вымышленную ситуацию? Чтобы показать, что теоретически существуют случаи, когда выбранное решение может перестать работать? Так это относится к вообще любому решению, в любом из них может быть сломана обратную совместимость.

P.S. И мне просто интересно, как можно случайно перепутать порядок ключей в разбираемых последовательно данных. А так же какого размера должен быть конфигурационный файл, чтобы скорость его разбора существенно на что-либо влияла.

Здравствуйте, anonymous, Вы писали:

A>Для чего мы сейчас будем обсуждать вымышленную ситуацию? Чтобы показать, что теоретически существуют случаи, когда выбранное решение может перестать работать?
Для того, чтобы показать, как плохо пользоваться невнятными спецификациями.
A>Так это относится к вообще любому решению, в любом из них может быть сломана обратную совместимость.
Нет. Если совместимость сломана в соответствии со спецификацией, то бага в нашем коде, и её нужно просто починить. Если она сломана в нарушение спецификации, то это бага библиотеки, и для неё нужно запросить фикс у проихзводителя.
А когда у нас есть спека, которая содержит UB, то невозможно однозначно понять, кто должен чинить проблему.

A>P.S. И мне просто интересно, как можно случайно перепутать порядок ключей в разбираемых последовательно данных.
Очень просто: в версии x алгоритм "кто первым встал, того и тапки" (добавление в linked list) заменяется на "дуэль побеждает стреляющий последним" (запись в одну ячейку хеша). Или наоборот.

A>А так же какого размера должен быть конфигурационный файл, чтобы скорость его разбора существенно на что-либо влияла.
Вы же не думаете, что кто-то в здравом уме пишет специализированный парсер JSON "для конфигурационных данных"? Промышленные парсеры точатся для максимально широкого применения — в том числе и в системах хранения документов, где JSON может запросто весить пару сотен мегабайт. Поэтому либо мы выбираем велосипед (с риском потом годами отлавливать мелких блох вроде корректной обработки уникод-суррогатов), либо промышленный парсер, на котором люди будут оттачивать адские штуки типа использования SSE3 для ускоренного поиска пунктуации в UTF8-потоке.

Здравствуйте, Sinclair, Вы писали:

A>>Для чего мы сейчас будем обсуждать вымышленную ситуацию? Чтобы показать, что теоретически существуют случаи, когда выбранное решение может перестать работать?
S>Для того, чтобы показать, как плохо пользоваться невнятными спецификациями.

Зачем мне это показывать?

A>>Так это относится к вообще любому решению, в любом из них может быть сломана обратную совместимость.
S>Нет. Если совместимость сломана в соответствии со спецификацией, то бага в нашем коде, и её нужно просто починить. Если она сломана в нарушение спецификации, то это бага библиотеки, и для неё нужно запросить фикс у проихзводителя. А когда у нас есть спека, которая содержит UB, то невозможно однозначно понять, кто должен чинить проблему.

Для чего мы сейчас будем обсуждать вымышленную ситуацию? Чтобы показать, что теоретически существуют случаи, когда выбранное решение может перестать работать?

Я не понимаю, что ты хочешь мне сказать.

A>>P.S. И мне просто интересно, как можно случайно перепутать порядок ключей в разбираемых последовательно данных.
S>Очень просто: в версии x алгоритм "кто первым встал, того и тапки" (добавление в linked list) заменяется на "дуэль побеждает стреляющий последним" (запись в одну ячейку хеша). Или наоборот.

И как же использование хеша при последовательном чтении данных перепутает ключи?

A>>А так же какого размера должен быть конфигурационный файл, чтобы скорость его разбора существенно на что-либо влияла.
S>Вы же не думаете, что кто-то в здравом уме пишет специализированный парсер JSON "для конфигурационных данных"?

Нет, не думаю, и что от этого размер конфигурационного файла начнёт сразу на что-то существенно влиять?

S>Промышленные парсеры точатся для максимально широкого применения — в том числе и в системах хранения документов, где JSON может запросто весить пару сотен мегабайт. Поэтому либо мы выбираем велосипед (с риском потом годами отлавливать мелких блох вроде корректной обработки уникод-суррогатов), либо промышленный парсер, на котором люди будут оттачивать адские штуки типа использования SSE3 для ускоренного поиска пунктуации в UTF8-потоке.

При чём тут системы хранения документов, если я сразу чётко обозначил область применения случаями, когда данные только читаются?

Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?

Забавно на самом деле.. Привычнее и намного приятнее читать HTML, чем JSON (например, яндексовский BEM)

<header class="header">
    <img class="logo">
    <form class="search-form">
        <input type="input">
        <button type="button"></button>
    </form>
    <div class="lang-switcher"></div>
</header>

{
    block: 'header',
    content : [
        { block : 'logo' },
        {
            block : 'search-form',
            content : [
                { block : 'input' },
                { block : 'button' }
            ]
        },
        { block : 'lang-switcher' }
    ]
}

Но конфиг файл для gruntjs выглядит куда приятнее какого-нибудь msbuild.

C>Единственное, что РЕАЛЬНО не хватает — это стандартные комментарии.

Стандартный подход писать комментарии и потом пропускать через JSMin перед парсингом или деплоем аналогично SASS/LESS -> CSS.

Здравствуйте, Sinclair, Вы писали:

S>Вы же не думаете, что кто-то в здравом уме пишет специализированный парсер JSON "для конфигурационных данных"? Промышленные парсеры точатся для максимально широкого применения — в том числе и в системах хранения документов, где JSON может запросто весить пару сотен мегабайт. Поэтому либо мы выбираем велосипед (с риском потом годами отлавливать мелких блох вроде корректной обработки уникод-суррогатов), либо промышленный парсер, на котором люди будут оттачивать адские штуки типа использования SSE3 для ускоренного поиска пунктуации в UTF8-потоке.

Хыхы, промышленный парсер JSON? Хм... ))) Вообще то на том же boost.spirit'e полноценный парсер json записывается в несколько строк (собственно грамматика) и при этом не уверен, что есть "профессиональные" специализированные json парсеры, которые обойдут такое решение по скорости. )))

_>Хыхы, промышленный парсер JSON? Хм... ))) Вообще то на том же boost.spirit'e полноценный парсер json записывается в несколько строк (собственно грамматика) и при этом не уверен, что есть "профессиональные" специализированные json парсеры, которые обойдут такое решение по скорости. )))

Не знаю, что из этого написано с boost.spirit'ом, но ВНЕЗАПНО разница есть: https://github.com/miloyip/nativejson-benchmark И довольно ощутимая.


И да. Промышленный JSON-парсер — это тот, который позволяет на одном сервере обрабатывать стопятьсот запросов, например, каждый из которых — JSON, и не становиться бутылочным горлышком.

Здравствуйте, vitaly_spb, Вы писали:

C>>Единственное, что РЕАЛЬНО не хватает — это стандартные комментарии.
_>Стандартный подход писать комментарии и потом пропускать через JSMin перед парсингом или деплоем аналогично SASS/LESS -> CSS.
Это понятно, но всё равно хочется стандартных комментариев.

Здравствуйте, alex_public, Вы писали:

_>Хыхы, промышленный парсер JSON? Хм... ))) Вообще то на том же boost.spirit'e полноценный парсер json записывается в несколько строк (собственно грамматика) и при этом не уверен, что есть "профессиональные" специализированные json парсеры, которые обойдут такое решение по скорости. )))
У меня есть парсер на SSE3 (тот же подход, что в Parabix), который даёт что-то около 2Гб парсинга в секунду на одном CPU.

Здравствуйте, Mamut, Вы писали:

_>>Хыхы, промышленный парсер JSON? Хм... ))) Вообще то на том же boost.spirit'e полноценный парсер json записывается в несколько строк (собственно грамматика) и при этом не уверен, что есть "профессиональные" специализированные json парсеры, которые обойдут такое решение по скорости. )))
M>Не знаю, что из этого написано с boost.spirit'ом, но ВНЕЗАПНО разница есть: https://github.com/miloyip/nativejson-benchmark И довольно ощутимая.

Тест от авторов одного из продуктов? ) И их продукт в этих тестах лидирует (сюрприз сюрприз)? Ну-ну. ))) А что там ещё за библиотека strdup с непревзойдённым быстродействием? ))) Вообще весёлая ссылка конечно. Что впрочем не говорит о неправильности твоего тезиса, т.к. он немного в другом.

M>И да. Промышленный JSON-парсер — это тот, который позволяет на одном сервере обрабатывать стопятьсот запросов, например, каждый из которых — JSON, и не становиться бутылочным горлышком.

Моя мысль была в том, что json парсер — это достаточно простая вещь, чтобы без проблем реализовывать её без всяких бутылочных горлышек. Хотя конечно же при должном умение можно и тут тормоза накрутить. Судя по некоторым сильно выдающимся пикам по твоей ссылке, имеется некий набор маргинально медленных и жрущих память решений. Но такое думаю можно найти в любых областях, даже самых простых.

M>>Не знаю, что из этого написано с boost.spirit'ом, но ВНЕЗАПНО разница есть: https://github.com/miloyip/nativejson-benchmark И довольно ощутимая.

_>Тест от авторов одного из продуктов? ) И их продукт в этих тестах лидирует (сюрприз сюрприз)? Ну-ну. )))

Что бы ты там не ну-нукал, вот тебе бенчмарк. Можешь проверить

_>А что там ещё за библиотека strdup с непревзойдённым быстродействием? )))

А, я понял. Чукча не читатель.

M>>И да. Промышленный JSON-парсер — это тот, который позволяет на одном сервере обрабатывать стопятьсот запросов, например, каждый из которых — JSON, и не становиться бутылочным горлышком.

_>Моя мысль была в том, что json парсер — это достаточно простая вещь,

Это никто и не отрицает. Но при этом
1. Есть «промышленные» парсеры, от которых главное, что нужно — это быстродействие
2. Быстродействие парсеров сильно разное

Здравствуйте, Cyberax, Вы писали:

_>>Хыхы, промышленный парсер JSON? Хм... ))) Вообще то на том же boost.spirit'e полноценный парсер json записывается в несколько строк (собственно грамматика) и при этом не уверен, что есть "профессиональные" специализированные json парсеры, которые обойдут такое решение по скорости. )))
C>У меня есть парсер на SSE3 (тот же подход, что в Parabix), который даёт что-то около 2Гб парсинга в секунду на одном CPU.

Ты про это http://parabix.costar.sfu.ca/wiki/ParabixTransform? Хм, любопытный подход. Хотя программировать потом такое конечно очень извратно. Но если кто-то всё же найдёт силы и напишет что-то (тот же парсер), то потом должен быть очень приятный результат.

Здравствуйте, Mamut, Вы писали:

_>>А что там ещё за библиотека strdup с непревзойдённым быстродействием? )))
M>А, я понял. Чукча не читатель.

Конечно, я картинки смотрел только. ))) Ну ок, прочитал и теперь ещё более худшего мнения об их способностях тестеров. )))

_>>Моя мысль была в том, что json парсер — это достаточно простая вещь,
M>Это никто и не отрицает. Но при этом
M>1. Есть «промышленные» парсеры, от которых главное, что нужно — это быстродействие

Меня просто несколько смешит термин "промышленный парсер" в приложение к маленькому и элементарному коду. )))

M>2. Быстродействие парсеров сильно разное

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