Здравствуйте, Sinix, Вы писали:
S>Хипстеры, сэр. S>Если серьёзно, то большинство людей руками туда лезть будут не чаще, чем в нынешний xml. Какая разница?
А аналоги XSD (для того же intellisense нужно вроде) и XSLT (хочу например html справку из XML .config файла делать) для json уже существуют? Или оно не надо?
Здравствуйте, andrey82, Вы писали:
A>А аналоги XSD (для того же intellisense нужно вроде) и XSLT (хочу например html справку из XML .config файла делать) для json уже существуют? Или оно не надо?
Тут как всегда: в студию автодополнение добавили (вплоть до имён и версий пакетов, если не забыл), проблемы остальных шерифа не колышут.
Чисто формально json-schema есть, но до xsd ей примерно как силуминовой отвёртке до мультитула. Аналогия удачная кстати, сценарии использования тоже отражает.
Здравствуйте, Sinix, Вы писали:
S>Если серьёзно, то большинство людей руками туда лезть будут не чаще, чем в нынешний xml. Какая разница?
Как по мне, так язык разметки, в котором нет поддержки комментариев, даже не должен и рассматриваться в качестве кандидатуры на использование в конфигурационных файлах приложения.
А в XML было ж всё. И комментарии эти, и трансформации, и валидация.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
Н>Вот что это за непотребство такое?
Ну имхо json это самый удобный вариант для конфигов. Категорически прост, древовиден, структуризован, типизирован и не так наворочен, как xml.
По личному опыту: xml трудно читать, количество скобок превышает все мыслимые пределы, закрывающие теги только мешают
Здравствуйте, Sheridan, Вы писали:
S>Ну имхо json это самый удобный вариант для конфигов.
Нет.
S>Категорически прост,
INI еще проще.
S>древовиден, структуризован,
Допустим.
S>типизирован
Wat?
S>По личному опыту: xml трудно читать, количество скобок превышает все мыслимые пределы, закрывающие теги только мешают
Запилы вида [{},[[{{}, [] читать еще сложнее.
И нет комментариев, Карл! Конфигурационный файл без возможности добавить в него комментарий -- это зло в чистом виде.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
S>>Если серьёзно, то большинство людей руками туда лезть будут не чаще, чем в нынешний xml. Какая разница?
Н>Как по мне, так язык разметки, в котором нет поддержки комментариев, даже не должен и рассматриваться в качестве кандидатуры на использование в конфигурационных файлах приложения.
Стандартный ответ json-фагов — можно добавить свойство "Comment"
Н>А в XML было ж всё. И комментарии эти, и трансформации, и валидация.
Но вот использовалось всё это по разному. В нашем приложении я переделывал XML сериализацию на Json, так всё стало гораздо лучше! Потому что XML был сделан вообще ужасно — он использовался только для потокового чтения и записи, но что-то найти в нём было абсолютно нереально.
Здравствуйте, Нахлобуч, Вы писали:
S>>Категорически прост, Н>INI еще проще.
Он не древовиден. Не типизирован.
S>>типизирован Н>Wat?
"строка", 1 — число
S>>По личному опыту: xml трудно читать, количество скобок превышает все мыслимые пределы, закрывающие теги только мешают Н>Запилы вида [{},[[{{}, [] читать еще сложнее.
Нифига. {} — хэш ключ-значение, [] — массив
Н>И нет комментариев, Карл! Конфигурационный файл без возможности добавить в него комментарий -- это зло в чистом виде.
Это зависит от того — решит ли разработчик использовать комментарии. Как минимум можно игнорировать ключи "comment".
Моя реализация читателя/писателя — умеет
Здравствуйте, Нахлобуч, Вы писали:
Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?
хихи Всё ровно наоборот: со времён хэмэлеизации прошло достаточно много времени, чтобы понять: XML не стал "большим всемогутером", ибо тяжеловесен, избыточен, неудобен, да и не может "абстрактный формат" вдруг стать "всеми понимаемым". Тот же *.ini — ВСЕ программы могут без труда его прочесть, а смысл? Без семантики (и поддержки самой программой) ЛЮБОЙ формат бесполезен.
Но в чём прекрасен JSON, так это в удобстве — он читаемый, ЛЕГКО (де)сериализуемый, поддерживает все мыслимые структуры (включая циклические), ну и его современное распространение говорит само за себя! Я его юзаю практически с первых упоминаний в сети (почти лет 10) — крайне удобно, все конфиги именно в нём. Думаю, формат заслужил свою славу, обидно только, что M$ тратит столько времени на "осознание очевидного". Тот же *.sln писал какой-то имбецил с питоном головного мозга, при всём том, что даже *.csproj — XML! Неконсистентность от тех, кто учит нас жить.
Здравствуйте, Kolesiki, Вы писали:
K>Но в чём прекрасен JSON, так это в удобстве — он читаемый, ЛЕГКО (де)сериализуемый, поддерживает все мыслимые структуры (включая циклические), ну и его современное распространение говорит само за себя!
Ну так сценарии использования у них разные, чего смешивать-то?
Как показывает практика, на более-менее сложных структурах json откровенно сливает.
И по удобству редактирования, и по тулзам, и по объёму выигрыш редко превышает 20%, и отсутствие комментов/дат тоже радости не добавляет.
Чтоб далеко не ходить: xml, json. На переносы строк в json внимания не обращаем — я их для читабельности оставил. Без них вообще каша получается.
Здравствуйте, Kolesiki, Вы писали:
K>Но в чём прекрасен JSON, так это в удобстве — он читаемый...
Мне приходилось сложные править XML'ки по 500 Kb весом, и их чтение не вызывало трудностей. Сложно себе представить такого же размера json, думаю, разобраться там будет нереально.
K> Я его юзаю практически с первых упоминаний в сети (почти лет 10) — крайне удобно, все конфиги именно в нём.
Всё зависит от размера и сложности конфигов. Шарповые проекты действительно сложными бывают, особенно когда нужна условная компиляция.
K>Тот же *.sln писал какой-то имбецил с питоном головного мозга...
О да, согласен.
K>Неконсистентность от тех, кто учит нас жить.
Кто нас только не учит жить
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Kolesiki, Вы писали: K>Здравствуйте, Нахлобуч, Вы писали: Н>>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON? K>хихи :) Всё ровно наоборот: со времён хэмэлеизации прошло достаточно много времени, чтобы понять: XML не стал "большим всемогутером", ибо тяжеловесен, избыточен, неудобен, да и не может "абстрактный формат" вдруг стать "всеми понимаемым". Тот же *.ini — ВСЕ программы могут без труда его прочесть, а смысл? Без семантики (и поддержки самой программой) ЛЮБОЙ формат бесполезен.
Когда ругают XML, обычно не знают, заменой чему он является
Здравствуйте, sambl4, Вы писали:
S>Но вот использовалось всё это по разному. В нашем приложении я переделывал XML сериализацию на Json, так всё стало гораздо лучше! Потому что XML был сделан вообще ужасно — он использовался только для потокового чтения и записи, но что-то найти в нём было абсолютно нереально.
В чём проблема с DOM + XPath? Если объёмы громадные, то что JSON, что XML будут тупить одинаково — нужна DB в качестве "искабельного" кэша.
Здравствуйте, sambl4, Вы писали:
S>Но вот использовалось всё это по разному. В нашем приложении я переделывал XML сериализацию на Json, так всё стало гораздо лучше! Потому что XML был сделан вообще ужасно — он использовался только для потокового чтения и записи, но что-то найти в нём было абсолютно нереально.
Что "всё" и чем "лучше"? И как json облегчает задачу "что-то найти в нём"?
xml и json могут парситься потоково (sax), могут строиться во внутреннее представление (dom).
Ещё у xml есть XPath, к json тоже можно подобное прикрутить (даже готовые реализации есть).
XSLT — у json такого нет (ошибаюсь?), но можно на любом скриптовом языке накатать.
XSD — у json нет подобной валидации.
Также у xml есть атрибуты, что для простых структур сильно сокращает оверхед по разметке (напомню, речь шла о конфигах).
То, что xml не (так) удобен для JS-программистов, не умаляет его достоинств.
Ну а касательно легкости чтения — json всё же сложнее читать, особенно, если начать с середины — по закорючкам сложно выбраться на нужный уровень (привет, cdecl.org)!, а по открывающим и закрывающим тегам xml таки проще это сделать.
Здравствуйте, Sinix, Вы писали:
S>Как показывает практика, на более-менее сложных структурах json откровенно сливает.
Ты хотел сказать — xml.
Даже по твоим ссылкам видно: S>Чтоб далеко не ходить: xml, json. На переносы строк в json внимания не обращаем — я их для читабельности оставил. Без них вообще каша получается.
В xml каша из тегов, в json чётко видно что к чему
Это называется мода. Был нормальный XML. Кучу инструментов для него придумали: простой декларативный DTD, мощнейшая XML Schema, какие-то Schematron-ы, XSLT и многое другое. Чуть ли не программы можно уже писать на этом XML-е. Но нет, он стал немоден, каждый уважающий себя студентик начал плеваться, как же так, в великом JavaScript-е ведь его неудобно использовать, какие-то XPath-ы надо учить, мне бы попроще чего, а давайте прямо этот жаваскрипт возьмём и запишем в файл. Лисперы тут икать начали.
Моё имхо — XML в текущий момент это шикарный инструмент. С прописанной грамотной XML Schema та же Intellij Idea позволяет писать этот XML практически как Java — на лету проверяет соответствие схеме, вываливает правильные автодополнения, ну ё-моё, чего ещё надо-то? А JSON — убожество, которое можно юзать только пока размер документа крошечный. А когда окунаешься в реальный мир и видишь там
}
}
}
]
}
}
]
}
то хочется немного старого доброго XML-я с закрывающими тегами.
Здравствуйте, flаt, Вы писали:
F>Ещё у xml есть XPath, к json тоже можно подобное прикрутить (даже готовые реализации есть).
Да чего там их реализовывать? Вот например моя
Использую кактотак
F>XSLT — у json такого нет (ошибаюсь?), но можно на любом скриптовом языке накатать. F>XSD — у json нет подобной валидации.
json не настолько каша, чтобы для работы требовались какие то специфические инструменты
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, vsb, Вы писали:
vsb>> А когда окунаешься в реальный мир и видишь там vsb>>то хочется немного старого доброго XML-я с закрывающими тегами.
S>А казалось бы, всего лишь навсего нужно открыть в редакторе с подсветкой блоков. Так нет же, ведро жидкого же вылить надо.
Это если все блоки у тебя на экран влазят (ну хотя-бы на два), то поможет. А если нет?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, vsb, Вы писали:
vsb>Кучу инструментов для него придумали: простой декларативный DTD, мощнейшая XML Schema, какие-то Schematron-ы, XSLT и многое другое.
Это хорошо.
vsb>А когда окунаешься в реальный мир и видишь там vsb>
Здравствуйте, Философ, Вы писали:
S>>А казалось бы, всего лишь навсего нужно открыть в редакторе с подсветкой блоков. Так нет же, ведро жидкого же вылить надо. Ф>Это если все блоки у тебя на экран влазят (ну хотя-бы на два), то поможет. А если нет?
Чтото я не понял, к чему тут размер экрана о0
любой элемент емеет свой2 значение и дочерние элементы, все они однородны
но по соглашению нижний регистр в названии это атрибуты, верхний — дочерние элементы
также по соглашению атрибуты можно писать в одну строчку
и можете минусовать я не вернусь!!!!!!
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, MTD, Вы писали:
MTD>>А чем это лучше?
vsb>Тем, что мы сидим в середине документа и видим контекст. Видим, в каком месте мы находимся и после какого тега надо начинать писать следующий.
И я вижу ]
Здравствуйте, Michael7, Вы писали:
M>А я думал, что SGML, чьим подмножеством он является (являлся поначалу), да и html тоже. Который появился раньше. Еще ASN.1 можно вспомнить.
В отличии от ваших джейсонов и хмл-ей, ASN.1 спокойно живёт и ещё переживёт всех.
Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?
Видимо их задолбал xml. Все-таки xml читать и править руками неудобно, он больше для автоматической обработки. Не, конечно есть всякие тулзы, типа XMLnotepad, но и они задалбывают. Если нужно что-то быстро добавить, удобнее файлик открыть в far'e. Остальные форматы не лучше. В общем нет в жизни счастья .
Здравствуйте, Нахлобуч, Вы писали:
Н>Вот что это за непотребство такое? Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?
Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?
JSON — это вообще странный зверек. Тут ща будет много неструктурированного текста.
Во-первых. JSON — это JavaScript Object Notation. Это его первое, главное, единственное, определяющее ключевое свойство. Из этого проистекают все его плюсы и минусы.
Во-вторых. Проистекающее из во-первых. JSON был создан в первую и определяющую очередь для веба. Для всех этих SPA (single page applications), которые громко вошли в этот мир под названием Web 2.0 (помните этот термин? )
Вспомните, что было практически единственным более-менее стандартным способом передачи данных между клиентов и сервером на момент появления JSON'а? Подсказка: термин AJAX расшифровывается как Asynchronous Javascript and XML.
С точки зрения веб-приложений JSON был спасением. В условиях достаточно маленьких скоростей середины двухтысячных использование JSON'а позволяло легко экономить ~30% на объемах передаваемых данных (или около ~10% если трафик gzip'ался). И вообще, до сих пор практически нет форматов сериализации, которые могли потягаться с JSON'ом в вебе.
У JSON'е есть еще одно свойство, которое у него образовалось совершенно случайно. Он легко читается людьми в объемах примерно около страницы экранного текста. Ну то есть обычно в тех пределах, что как раз передаются между сервером и веб-страницами. Это — sweet spot JSON'а, в котором он кроет большинство других форматов, как бык овцу: бинарные форматы вообще нечитаемы людьми, XML на таких объемах мешает количеством лишней информации, а прочие форматы типа YAML в разы сложнее JSON'а и могут иметь весьма нетривиальные ловушки на ровном месте (спецификация YAML'а — легко подходит под пару сотен страниц).
Промежуточный итог. JSON:
— нативен для веба
— легко читается и понимается людьми на маленьких объемах
— сроки в нем строки, целые числа — целые числа, массивы — массивы, объекты — объекты
— вся спецификация JSON'а умещается в одну страницу
— для него тривиально написать парсер и сериализатор на любом языке
Но
JSON — это кровь от крови JavaScript'а и плоть от плоти веба. Соответсвенно, использование его где-либо в других местах будет вызывать неизбежный impedance mismatch.
Типы. Типы в JSON'е — это типы JavaScript'а. Как ни странно, это вызывает проблемы в большом количестве языков — от вопросов, как представлять объекты, которые на самом деле списки «ключ-значение», до проблем за конвертацией float'ов.
Да и сами типы очень ограничены. Это — строка, числа, ключ-значение и массив. Всё. В качестве квеста предлагаю поискать, как стандартным образом сериализовать в JSON дату, например. Это не прописано в спеке, а про ISO 8601, как оказалось, знают полтора человека в интернете. .NET, например, генерит что-то типа "\/Date(1320825600000-0800)\/"
Инструментирование. В частности — валидация. Если для того же XML есть XSD, в котором можно задать правила построения типов (практически) любой сложности, для JSON'а это отсутсвует. Есть на самом деле достаточно неплохой черновик стандарта JSON Schema, но на практике ей пользуется полтора человека и есть примерно ноль инструментов, с ней работающих (на правах рекламы очень рекомендую https://github.com/klarna/jesse. К сожалению, тулзу для создания и генерации схем Кларна так и не опенсорснула )
Это выливается в невозможность внятно обрабатывать большие объемы JSON'а. Практически максимум, что из себя могут выдавить тулзы — это «expected comma in line 2900 column 4» при том, что ошибка может быть на двести строчек выше.
Так как JSON — это формат сериализации, использование его для чего-либо другого (например, для конфигов), моментально приводит к разннобразного уровня проблемам: от нечитаемости до impendance mismatch с языками, которые должны его читать, до невозможности писать комментарии, до... до...
Что-то еще хотел написать, но уже не помню, что Если вспомню, допишу.
Во всех этих разговорах о, якобы, простоте и читабельности текстовых форматов, наподобие xml и json, всегда забывают об одной важной теме: данные должны быть отделены от представления! Это, по сути, аксиома современного проектирования.
Допустим, нам нужно хранить данные о людях: имя и возраст.
CSV:
А теперь финальный штрих: xml не только с отступами, но и с подсветкой синтаксиса! В таком варианте и атрибуты хорошо отличимы от тэгов.
Вставил картинкой, т. к. кывт не может в подсветку xml.
Полагаю, никто не будет возражать, что последний вариант самый читабельный? Между тем, во всех четырёх вариантах данные одни и те же, изменилось лишь их представление.
Суть в чём: любой специализированный xml-редактор позволяет нажатием одной кнопки отформатировать документ из первого варианта в четвёртый. То есть компактные данные будут представлены в удобном для восприятия виде. И сохранять специализированный xml-редактор может (должен) без отступов (чтобы лишнее место не занимать).
То есть читабельность для человека должен обеспечивать софт, а не сам формат данных!
Я уже давно пришёл к выводу, что данные должны храниться в компактном (чтобы занимать мало место и быстро читаться/записываться/пересылаться по сети) и удобном для парсинга (чтобы быстро читаться/записываться/индексироваться в случае необходимости) формате.
Для того же xml есть бинарные форматы. Реализация Microsoft.
Увы, с этим одна глобальная проблема: нет такого единого стандартизированного формата.
Многие скажут, что невозможность воспользоваться обычным текстовым редактором типа Notepad ставит крест на идее двоичного формата. Но, положа руку на сердце, часто вы им пользуетесь? Или всё же предпочтёте что-то получше, хотя бы типа Notepad++. Во многих базах данных есть тип данных xml — понятно, что хранится он в распарсенном виде, то есть в нечитаемом для человека. Является ли это препятствием для его использования? Полезете ли вы текстовым редактором в файл(ы) БД?
Итог: нужен единый стандартизированный компактный двоичный формат и специализированный редактор для работы с ним на каждой платформе.
(Тут картинка xkcd про стандарты).
Здравствуйте, koodeer, Вы писали:
K>Во всех этих разговорах о, якобы, простоте и читабельности текстовых форматов, наподобие xml и json, всегда забывают об одной важной теме: данные должны быть отделены от представления! Это, по сути, аксиома современного проектирования. K>Допустим, нам нужно хранить данные о людях: имя и возраст.
K>JSON: K>
Здравствуйте, Нахлобуч, Вы писали:
Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?
может, им тупо неохота развивать богомерзкий msxml.dll (как-то читал в msdn про одну из нужных мне фич, что де используйте System.Xml или как его из .net, а msxml — идет в задницу).
Здравствуйте, RonWilson, Вы писали:
RW>может, им тупо неохота развивать богомерзкий msxml.dll (как-то читал в msdn про одну из нужных мне фич, что де используйте System.Xml или как его из .net, а msxml — идет в задницу).
Неа, и сборка и старых и новых проектов — managed-код.
Здравствуйте, RonWilson, Вы писали:
RW>может, им тупо неохота развивать богомерзкий msxml.dll (как-то читал в msdn про одну из нужных мне фич, что де используйте System.Xml или как его из .net, а msxml — идет в задницу).
Там кроме производительности развивать было нечего, да и по производительности он в сравнении с конкурентами весьма крепкий середнячок. Кроме отсутствия XSLT 2.0 в MSXML 6.0 всё идеально
Здравствуйте, koodeer, Вы писали:
K>Во всех этих разговорах о, якобы, простоте и читабельности текстовых форматов, наподобие xml и json, всегда забывают об одной важной теме: данные должны быть отделены от представления! Это, по сути, аксиома современного проектирования. K>XML:
Не, раз мы боремся за синтаксический оверхед, то сравнивать надо с
Смотрим на json выше, что-то оно нифига не читабельней
K>То есть читабельность для человека должен обеспечивать софт, а не сам формат данных!
Кэп: именно эта логика закопала эдак с дюжину форматов. Для самых актуальных сценариев бинарные форматы сливают практически во всём, от стоимости поддержки и до расширяемости. Про мелочи типа сравнения файлов, обработку в веб-фронтэнде и эффективность сжатия потока в "экономном" бинарном формате я и говорить не буду.
K>Я уже давно пришёл к выводу, что данные должны храниться в компактном (чтобы занимать мало место и быстро читаться/записываться/пересылаться по сети) и удобном для парсинга (чтобы быстро читаться/записываться/индексироваться в случае необходимости) формате.
Великолепная идея. Осталось придумать способ запихнуть в этот формат поддержку произвольных кодировок, схем данных, версионность ("старый" формат должен гарантированно читаться и спустя n лет), комментарии, универсальный формат дат и больших чисел и ещё с десяток нюансов. Ну и обосновать, чем получившийся монстр будет лучше старого-доброго xml. В общем как только — так сразу приходите
K>Многие скажут, что невозможность воспользоваться обычным текстовым редактором типа Notepad ставит крест на идее двоичного формата. Но, положа руку на сердце, часто вы им пользуетесь?
Я пользуюсь тем, что есть под рукой — от vi на удаленном сервере до IntelliJ IDEA. И да. Был случай, когда пришлось глазами просматривать примерно 3-мегабайтный XML-файл vim'ом.
K>Или всё же предпочтёте что-то получше, хотя бы типа Notepad++. Во многих базах данных есть тип данных xml — понятно, что хранится он в распарсенном виде, то есть в нечитаемом для человека. Является ли это препятствием для его использования? Полезете ли вы текстовым редактором в файл(ы) БД?
XML-редактором тоже в базу не лезут. Что ты хочешь сказать-то?
K>Итог: нужен единый стандартизированный компактный двоичный формат и специализированный редактор для работы с ним на каждой платформе. K>(Тут картинка xkcd про стандарты).
1. Именно.
2. ASN.1, например, есть. Но им пользуется полтора человека.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, RonWilson, Вы писали:
RW>>может, им тупо неохота развивать богомерзкий msxml.dll (как-то читал в msdn про одну из нужных мне фич, что де используйте System.Xml или как его из .net, а msxml — идет в задницу). S>Неа, и сборка и старых и новых проектов — managed-код.
Здравствуйте, α, Вы писали:
α>Здравствуйте, RonWilson, Вы писали:
RW>>может, им тупо неохота развивать богомерзкий msxml.dll (как-то читал в msdn про одну из нужных мне фич, что де используйте System.Xml или как его из .net, а msxml — идет в задницу).
α>Там кроме производительности развивать было нечего, да и по производительности он в сравнении с конкурентами весьма крепкий середнячок. Кроме отсутствия XSLT 2.0 в MSXML 6.0 всё идеально
ну тут наверное да, если бы не COM.. а так даже и сравнивать не с чем, особенно после убойных багов, которые до сих пор в tinyxml и поделии tinyxpath, что вообще эпичное творение
Здравствуйте, RonWilson, Вы писали:
S>>Неа, и сборка и старых и новых проектов — managed-код. RW>старых понятно, но про новые не понял)
Ну откуда в портируемых dnx projects системе проектов возьмётся завязка на unmanaged код?
Не забываем, что одна из возможностей dnx host — горячая компиляция, с поддержкой обновления исходников в рантайме.
Здравствуйте, aloch, Вы писали:
A>Здравствуйте, RonWilson, Вы писали:
RW>>ну тут наверное да, если бы не COM..
A>А что не так с COM? Мне он никогда не мешал, наоборот...
да тут без предрассудков, в целом, просто зачем это делать было в рамках COM, если только бы одно не вспомнилось, что даже excel использует его же объекты для stylesheets призагрузке xml, к примеру.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, flаt, Вы писали:
F>>Ещё у xml есть XPath, к json тоже можно подобное прикрутить (даже готовые реализации есть). S>Да чего там их реализовывать? Вот например моя S>Использую кактотак S>
RW>и как в это запихать условную выборку, или месье любит аля select * from tbl where id=252?
В смысле подставить в sql запрос данные из конфига? Как всегда, забиндить. Конретный вариант зависит от движка, но в общем случае кактотак:
db->query("select * from tbl where id=?", config->folder("network")->folder("listen")->file("port")->get(252 /*default*/));
Здравствуйте, koodeer, Вы писали:
K>Во всех этих разговорах о, якобы, простоте и читабельности текстовых форматов, наподобие xml и json, всегда забывают об одной важной теме: данные должны быть отделены от представления! Это, по сути, аксиома современного проектирования.
Я не понял почему вы форматирование называете представлением. Особенно в контексте проектирования.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Michael7, Вы писали:
M>>А я думал, что SGML, чьим подмножеством он является (являлся поначалу), да и html тоже. Который появился раньше. Еще ASN.1 можно вспомнить. K>В отличии от ваших джейсонов и хмл-ей, ASN.1 спокойно живёт и ещё переживёт всех.
Мне эта жизнь ASN.1 сильно напоминает нынешнюю ситуацию с хвойными и как Еськов писал про неё:
Покрытосеменные возникли в начале мелового периода, первоначально как ценофобы — растения, не входящие в закономерные, сложившиеся в длительной коэволюции сукцессионные ряды. Они росли в качестве "сорной" растительности по свободным от других растений участкам (на речных отмелях, береговых оползнях, гарях), которые соседствовали с гораздо более обширными участками, занятыми зрелыми сообществами мезофитной растительности. Основой стремительной среднемеловой экспансии цветковых стало то, что им удалось закрепиться в качестве нормальной пионерной растительности — для чего решающими факторами стали их исходная энтомофильность и наличие среди них травянистых форм (что во много раз убыстряет зарастание поврежденных участков). Покрытосеменные не пытались потеснить всю мезофитную растительность, что было абсолютно нереально; они "всего-навсего" конкурентно вытеснили прежних пионеров — и тем самым блокировали все последующие стадии мезофитной экогенетической сукцессии. Разрушение существовавших в то время закономерных сукцессионных рядов (попросту говоря — мезофитная растительность продолжала существовать там, где она существует, но потеряла способность восстанавливаться после экзогенных нарушений), вызвало полный развал мезозойских наземных экосистем и массовое вымирание входивших в них животных; наиболее интенсивно эта деструкция шла в альбе (захватывая конец апта и начало сеномана).
В старых применениях оно может жить ещё хоть вечно, за компанию к упоминавшемуся тут, не к ночи будь сказано, X12, но если ты мне покажешь хоть один пример новой технологии (а не расширения/дополнения существующих), где применён ASN.1, за последние 15 лет, я буду удивлён. По-моему, последним героическим движением в эту сторону было H.323.
Здравствуйте, Mamut, Вы писали:
M>Типы. Типы в JSON'е — это типы JavaScript'а. Как ни странно, это вызывает проблемы в большом количестве языков — от вопросов, как представлять объекты, которые на самом деле списки «ключ-значение», до проблем за конвертацией float'ов.
Ну вообще-то списки ключ-значение — это основа _любой_ структурированной форматной схемы. ASN.1, XML, JSON, даже ini файлы (хотя в последнем случае нет принципиально неограниченной вложенности). А иначе и не будет в задаче сериализовать что угодно в поток октетов, независимо от того, ограничены мы текстовыми представлениями или нет, и чтобы это хоть как-то было структурно сгруппировано. Конечно, везде введут свои грабельки — в ASN.1 это будет не name-value, а type-length-value, с косвенным кодированием name в виде порядка полей и context-specific type, в XML не будет бинарных данных (base64, cdata и т.п. это хаки), во внутренних сериализациях Python, Erlang и прочих будут только свои типы и укладка на них...
Вот если бы там делали передачу, например, прототипов объектов JS — были бы тяжёлые гайки. А так — просто ещё один вариант натягивания совы на глобус с выбором компромисса между целевыми характеристиками.
А вот с конкретными представлениями данных уже проблемно, согласен. Начиная с float, которое не float (NaN, INF запрещены), далее строками, которые только юникод (для передачи произвольной бинарки нам пришлось выбирать между укладкой в base64 и конверсией iso-8859-1 -> utf-8). Любые данные так можно прохачить передачей текста, но именно хаком это и будет.
M>Да и сами типы очень ограничены. Это — строка, числа, ключ-значение и массив. Всё. В качестве квеста предлагаю поискать, как стандартным образом сериализовать в JSON дату, например. Это не прописано в спеке, а про ISO 8601, как оказалось, знают полтора человека в интернете. .NET, например, генерит что-то типа "\/Date(1320825600000-0800)\/"
Я правильно понял, что это unixtime в миллисекундах плюс пояс?
В XML тоже жёсткого ограничения нет, но, насколько я понял XSD, там ISO8601.
M>Инструментирование. В частности — валидация. Если для того же XML есть XSD, в котором можно задать правила построения типов (практически) любой сложности, для JSON'а это отсутсвует. Есть на самом деле достаточно неплохой черновик стандарта JSON Schema, но на практике ей пользуется полтора человека и есть примерно ноль инструментов, с ней работающих (на правах рекламы очень рекомендую https://github.com/klarna/jesse. К сожалению, тулзу для создания и генерации схем Кларна так и не опенсорснула )
M>Это выливается в невозможность внятно обрабатывать большие объемы JSON'а. Практически максимум, что из себя могут выдавить тулзы — это «expected comma in line 2900 column 4» при том, что ошибка может быть на двести строчек выше.
Да, тут проблема. Но при отсутствии парности тегов вообще локальное обнаружение ошибки становится крайне сложным, проблема типа незакрытой кавычки может тянуться до конца входного потока.
M>Так как JSON — это формат сериализации, использование его для чего-либо другого (например, для конфигов), моментально приводит к разннобразного уровня проблемам: от нечитаемости до impendance mismatch с языками, которые должны его читать, до невозможности писать комментарии, до... до...
То, что комментарии можно писать в XML, среди данного класса средств является исключением
DO>Видимо их задолбал xml. Все-таки xml читать и править руками неудобно, он больше для автоматической обработки. Не, конечно есть всякие тулзы, типа XMLnotepad, но и они задалбывают. Если нужно что-то быстро добавить, удобнее файлик открыть в far'e.
а в чём проблема редактирвоания XML в FARе?
DO>Остальные форматы не лучше. В общем нет в жизни счастья .
как уже сказали, АСН.1 — наше всё.
Здравствуйте, sambl4, Вы писали:
Н>>Как по мне, так язык разметки, в котором нет поддержки комментариев, даже не должен и рассматриваться в качестве кандидатуры на использование в конфигурационных файлах приложения. S>Стандартный ответ json-фагов — можно добавить свойство "Comment"
Это если комментарии надо сохранить при чтении и последующей записи. А иначе лучше дублировать ключи, в первом комментарий, во втором данные:
Здравствуйте, anonymous, Вы писали:
S>>Стандартный ответ json-фагов — можно добавить свойство "Comment"
A>Это если комментарии надо сохранить при чтении и последующей записи. А иначе лучше дублировать ключи, в первом комментарий, во втором данные:
Вот в этом вся прелесть json-а: даже сами авторы не умеют в стандарты.
RFC7159:
The names within an object SHOULD be unique
Явовская реализация от автора json тоже не поддерживает дубликаты имён.
Но: параллельно с rfc прекрасно себе существует "более официальный" ECMA-404. И в нём про ограничение на уникальность упомянуть забыли.
Честное слово, иногда мне кажется, что ecma committee вдохновлялись старой шуткой про Страуструпа и рынок труда: нет ни одних граблей, на которые ещё не успели наступить и с вдохновением оттоптаться.
Здравствуйте, Sinix, Вы писали:
A>>Это если комментарии надо сохранить при чтении и последующей записи. А иначе лучше дублировать ключи, в первом комментарий, во втором данные: S>Вот в этом вся прелесть json-а: даже сами авторы не умеют в стандарты. RFC7159:
The names within an object SHOULD be unique
SHOULD не MUST. См. RFC 2119.
S>Явовская реализация от автора json тоже не поддерживает дубликаты имён.
Это всего лишь проблема реализации. Не один из стандартов не запрещает явно дублировать ключи.
A>SHOULD не MUST. См. RFC 2119.
Я-то в курсе. А вот авторы, к сожалению, нет. О чём и писал.
A>Это всего лишь проблема реализации.
Перевожу с маркетингового на человеческий: "валидный" json может:
— Прочитаться нормально
— Не прочитаться вообще
— Прочитаться, но с комментариями вместо значений.
Здравствуйте, 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 — вполне нормальная ситуация. Ни на что разумное это не отображается (даже мультикарты не спасут). Так что с 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-потоке.
При чём тут системы хранения документов, если я сразу чётко обозначил область применения случаями, когда данные только читаются?
Здравствуйте, Sinclair, Вы писали:
S>Вы же не думаете, что кто-то в здравом уме пишет специализированный парсер JSON "для конфигурационных данных"? Промышленные парсеры точатся для максимально широкого применения — в том числе и в системах хранения документов, где JSON может запросто весить пару сотен мегабайт. Поэтому либо мы выбираем велосипед (с риском потом годами отлавливать мелких блох вроде корректной обработки уникод-суррогатов), либо промышленный парсер, на котором люди будут оттачивать адские штуки типа использования SSE3 для ускоренного поиска пунктуации в UTF8-потоке.
Хыхы, промышленный парсер JSON? Хм... ))) Вообще то на том же boost.spirit'e полноценный парсер json записывается в несколько строк (собственно грамматика) и при этом не уверен, что есть "профессиональные" специализированные json парсеры, которые обойдут такое решение по скорости. )))
_>Хыхы, промышленный парсер JSON? Хм... ))) Вообще то на том же boost.spirit'e полноценный парсер json записывается в несколько строк (собственно грамматика) и при этом не уверен, что есть "профессиональные" специализированные json парсеры, которые обойдут такое решение по скорости. )))
И да. Промышленный 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. Быстродействие парсеров сильно разное
Я ещё в предыдущем сообщение написал, что с этим и не спорю. ) При должном умение тормоза можно интегрировать куда угодно. )))
Здравствуйте, alex_public, Вы писали:
_>Ты про это http://parabix.costar.sfu.ca/wiki/ParabixTransform? Хм, любопытный подход. Хотя программировать потом такое конечно очень извратно. Но если кто-то всё же найдёт силы и напишет что-то (тот же парсер), то потом должен быть очень приятный результат.
Я так понял, что "потом" уже наступило:
У меня есть парсер на SSE3 (тот же подход, что в Parabix), который даёт что-то около 2Гб парсинга в секунду на одном CPU.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Хыхы, промышленный парсер JSON? Хм... ))) Вообще то на том же boost.spirit'e полноценный парсер json записывается в несколько строк (собственно грамматика) и при этом не уверен, что есть "профессиональные" специализированные json парсеры, которые обойдут такое решение по скорости. )))
Целое стадо разных людей до падежа скота пилит джсон парсеры, но похоже, посоны просто не разобрались в кунфу boost.spirit. Эх, измельчали сиплюсники, измельчали.
P.S. boost.spirit == парсер-комбинаторы. Его область применения это простые грамматики, которые всерьез обработаны вручную. Фактически, recursive descent только без единой оптимизации. Ну, ты понял
Здравствуйте, alex_public, Вы писали:
_>Моя мысль была в том, что json парсер — это достаточно простая вещь, чтобы без проблем реализовывать её без всяких бутылочных горлышек.
Что-то не верю я в это смелое утверждение. Интуитивно кажется, что ваши представления о том, как в три строки реализовать парсер JSON дадут во-первых — некорректную, а во-вторых — неоптимальную реализацию. Про SSE3 уже откомментировали.
Про то, что до сих пор неясно, как обрабатывать одноименные атрибуты, уже тоже откомментировали. Вот ваш мегапарсер на спирите, он что будет делать в таком случае? И почему вы думаете, что это — правильное решение?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
_>>Ты про это http://parabix.costar.sfu.ca/wiki/ParabixTransform? Хм, любопытный подход. Хотя программировать потом такое конечно очень извратно. Но если кто-то всё же найдёт силы и напишет что-то (тот же парсер), то потом должен быть очень приятный результат. S>Я так понял, что "потом" уже наступило: S>
S>У меня есть парсер на SSE3 (тот же подход, что в Parabix), который даёт что-то около 2Гб парсинга в секунду на одном CPU.
Ну на сайте того же Parabix есть упоминание только о реализации grep в качестве примера их технологии. Понятно, что json парсер даже проще, так что задача вполне выполнима. Но и её кто-то должен сделать, что совсем не тривиально с учётом особенностей данного подхода. Так что подождём ответа Cyberax'а с деталями.
Здравствуйте, alex_public, Вы писали:
_>Моя мысль была в том, что json парсер — это достаточно простая вещь, чтобы без проблем реализовывать её без всяких бутылочных горлышек.
Если бы написал хотябы несколько нетривиальных парсеров, то знал бы, что даже простой (на первый взгляд) парсер может быть очень сложным реализации. Более того, самые быстрые парсеры оказываются на практике самыми сложными. Так что "без проблем реализовать" и "без бутылочных горлышек" зачастую взаимоисключающие вещи.
вот пример парсера JSON с нуля на F# http://fsharpforfunandprofit.com/posts/understanding-parser-combinators/ 4 статьи и куча зубодробительного кода, просто чтобы сделать парсер (и понять как сделать) на комбинаторах, который по сути самый медленный из всех возможных.
Аналогичный код на C++ будет по объему в 2-3 раза больше. Я для проверки делал решение Problem K на C++ и на F#, разница в объеме кода примерно в 3 раза.
Здравствуйте, Sinclair, Вы писали:
_>>Моя мысль была в том, что json парсер — это достаточно простая вещь, чтобы без проблем реализовывать её без всяких бутылочных горлышек. S>Что-то не верю я в это смелое утверждение. Интуитивно кажется, что ваши представления о том, как в три строки реализовать парсер JSON дадут во-первых — некорректную, а во-вторых — неоптимальную реализацию. Про SSE3 уже откомментировали.
Про использование SIMD для текстовых парсеров я действительно был не в курсе, признаю. Правда я вот очень сомневаюсь, что данная хитрая технология применяется в каком-то из так называемых "промышленных" парсеров json. ) Максимум там применяется что-то вроде пропусков пробелов с помощью SIMD, но это даже близко не имеет отношения к описываемой технологии битовых потоков и не даёт каких-то ощутимых эффектов.
Здравствуйте, gandjustas, Вы писали:
_>>Моя мысль была в том, что json парсер — это достаточно простая вещь, чтобы без проблем реализовывать её без всяких бутылочных горлышек. G>Если бы написал хотябы несколько нетривиальных парсеров, то знал бы, что даже простой (на первый взгляд) парсер может быть очень сложным реализации. Более того, самые быстрые парсеры оказываются на практике самыми сложными. Так что "без проблем реализовать" и "без бутылочных горлышек" зачастую взаимоисключающие вещи.
CSV подходит под нетривиальный парсер? ) А JSON подходит? )
G>вот пример парсера JSON с нуля на F# http://fsharpforfunandprofit.com/posts/understanding-parser-combinators/ 4 статьи и куча зубодробительного кода, просто чтобы сделать парсер (и понять как сделать) на комбинаторах, который по сути самый медленный из всех возможных. G>Аналогичный код на C++ будет по объему в 2-3 раза больше. Я для проверки делал решение Problem K на C++ и на F#, разница в объеме кода примерно в 3 раза.
А зачем писать парсер с нуля?) Естественно надо пользоваться удобными инструментами. О чём и было сказано в моём первом сообщение.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>Моя мысль была в том, что json парсер — это достаточно простая вещь, чтобы без проблем реализовывать её без всяких бутылочных горлышек. G>>Если бы написал хотябы несколько нетривиальных парсеров, то знал бы, что даже простой (на первый взгляд) парсер может быть очень сложным реализации. Более того, самые быстрые парсеры оказываются на практике самыми сложными. Так что "без проблем реализовать" и "без бутылочных горлышек" зачастую взаимоисключающие вещи.
_>CSV подходит под нетривиальный парсер? ) А JSON подходит? )
CSV на несколько порядков проще, так как CSV описывается регулярной грамматикой. JSON в этом плане почти также сложен, как XML.
G>>вот пример парсера JSON с нуля на F# http://fsharpforfunandprofit.com/posts/understanding-parser-combinators/ 4 статьи и куча зубодробительного кода, просто чтобы сделать парсер (и понять как сделать) на комбинаторах, который по сути самый медленный из всех возможных. G>>Аналогичный код на C++ будет по объему в 2-3 раза больше. Я для проверки делал решение Problem K на C++ и на F#, разница в объеме кода примерно в 3 раза. _>А зачем писать парсер с нуля?) Естественно надо пользоваться удобными инструментами. О чём и было сказано в моём первом сообщение.
Написание парсера с нуля полезно как упражнение на понимание проблем и их решений. Если не понимаешь этих проблем, то вряд ли сделаешь парсер с приемлемой производительностью.
Задача парсинга — одна из немногих, которая "в лоб" не решается. Максимум что может написать человек без предварительной подготовки — простой парсер рекурсивного спуска, который довольно слаб или сильно тормозит.
Здравствуйте, Sinclair, Вы писали:
S>Что-то не верю я в это смелое утверждение. Интуитивно кажется, что ваши представления о том, как в три строки реализовать парсер JSON дадут во-первых — некорректную, а во-вторых — неоптимальную реализацию. Про SSE3 уже откомментировали.
Это, кстати, не так. JSON настолько простой, что наивная реализация на каком-нибудь генераторе парсеров вполне может быть верной с первого раза.
Причём, будет работать со скоростью, вполне достаточной для подавляющего большинства практических применений. Для XML такое себе представить трудно — до сих пор в крупных парсерах ошибки находят.
В нашем случае экстремальный парсер делался для кода, который с помощью DPDK коммутирует JSON-сообщения на паре 10Гб сетевых интерфейсов. Причём он особо не нужен оказался, и без него можно было бы обойтись, но хотелось позаниматься спортивным программированием для разнообразия.
S>Про то, что до сих пор неясно, как обрабатывать одноименные атрибуты, уже тоже откомментировали. Вот ваш мегапарсер на спирите, он что будет делать в таком случае? И почему вы думаете, что это — правильное решение?
Одноимённые атрибуты запрещены. Кидать исключение в этом случае надо.
Здравствуйте, alex_public, Вы писали: _>Ну на сайте того же Parabix есть упоминание только о реализации grep в качестве примера их технологии. Понятно, что json парсер даже проще, так что задача вполне выполнима. Но и её кто-то должен сделать, что совсем не тривиально с учётом особенностей данного подхода. Так что подождём ответа Cyberax'а с деталями.
Несколько лет назад на этом форуме пробегала ссылка на парсер XML на основе данной технологии. Не думаю, что JSON парсер принципиально сложнее.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Про использование SIMD для текстовых парсеров я действительно был не в курсе, признаю. Правда я вот очень сомневаюсь, что данная хитрая технология применяется в каком-то из так называемых "промышленных" парсеров json.
Пока — нет. Но те, кто выбирает "три строки на спирите" для таких вещей, гарантированно отрезают себя от передовых достижений.
Весь смысл опоры на 3rd-party — в том, что там пацаны специализируются на своей работе, и пока мы пилим наше супер-приложение, они улучшают парсер независимо от нас.
И ключ к такой международной кооперации как раз во внятной спеке, на которую мы можем полагаться.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
DO>>Видимо их задолбал xml. Все-таки xml читать и править руками неудобно, он больше для автоматической обработки. Не, конечно есть всякие тулзы, типа XMLnotepad, но и они задалбывают. Если нужно что-то быстро добавить, удобнее файлик открыть в far'e. DA>а в чём проблема редактирвоания XML в FARе?
В том, что XML — это в общем случае бинарь, а не текстовик. И иногда эта кажущаяся текстовость формата сильно бьёт в лоб любителям "подправить тут по-бырику английский на русский" и т.п.
Здравствуйте, gandjustas, Вы писали:
_>>CSV подходит под нетривиальный парсер? ) А JSON подходит? ) G>CSV на несколько порядков проще, так как CSV описывается регулярной грамматикой. JSON в этом плане почти также сложен, как XML.
JSON почти также сложен, как XML?
_>>А зачем писать парсер с нуля?) Естественно надо пользоваться удобными инструментами. О чём и было сказано в моём первом сообщение. G>Написание парсера с нуля полезно как упражнение на понимание проблем и их решений. Если не понимаешь этих проблем, то вряд ли сделаешь парсер с приемлемой производительностью.
В качестве обучения конечно же полезно. Но мы тут вроде бы совсем другое обсуждаем...
G>Задача парсинга — одна из немногих, которая "в лоб" не решается. Максимум что может написать человек без предварительной подготовки — простой парсер рекурсивного спуска, который довольно слаб или сильно тормозит.
Здравствуйте, Mr.Delphist, Вы писали:
DO>>>Видимо их задолбал xml. Все-таки xml читать и править руками неудобно, он больше для автоматической обработки. Не, конечно есть всякие тулзы, типа XMLnotepad, но и они задалбывают. Если нужно что-то быстро добавить, удобнее файлик открыть в far'e. DA>>а в чём проблема редактирвоания XML в FARе?
MD>В том, что XML — это в общем случае бинарь, а не текстовик. И иногда эта кажущаяся текстовость формата сильно бьёт в лоб любителям "подправить тут по-бырику английский на русский" и т.п.
Тогда и код на C/Delphi/LISP/etc. — бинарь, а не текстовик.
Здравствуйте, Sinclair, Вы писали:
_>>Про использование SIMD для текстовых парсеров я действительно был не в курсе, признаю. Правда я вот очень сомневаюсь, что данная хитрая технология применяется в каком-то из так называемых "промышленных" парсеров json. S>Пока — нет. Но те, кто выбирает "три строки на спирите" для таких вещей, гарантированно отрезают себя от передовых достижений. S>Весь смысл опоры на 3rd-party — в том, что там пацаны специализируются на своей работе, и пока мы пилим наше супер-приложение, они улучшают парсер независимо от нас.
Думаю что в подавляющем большинстве обсуждаемых тут случаев (посмотри о чём была речь выше), возможностей парсера на базе спирита более чем хватит.
Однако если мне потребуется работа с JSON в моём проекте, я не побегу делать парсер на спирите, а возьму готовую библиотечку. Но совсем не потому что такой парсер медленный или некорректный. А потому что кроме парсера для работы с JSON понадобится ещё и соответствующая иерархия классов с перегрузками нужных операторов (это ещё более тривиально чем парсер, но ещё более лениво делать самому) и преобразование обратно в строку (ещё более тривиально, но опять же лень). Так что готовое интегрированное решение (кстати внутри оно может быть на чём угодно, включая и spirit) очевидно удобнее. А спирит скорее подходит для более редких форматов, для которых нет удобных готовых библиотек.
Ну а про "несколько строк на спирите" я упомянул в качестве оценки сложности парсера JSON и сомнительности выражения "промышленные парсеры json". )))
S>И ключ к такой международной кооперации как раз во внятной спеке, на которую мы можем полагаться.
Это о чём вообще речь? ) Об api библиотек? Так он же у каждой библиотеки свой...
Здравствуйте, netch80, Вы писали:
N>В старых применениях оно может жить ещё хоть вечно, за компанию к упоминавшемуся тут, не к ночи будь сказано, X12, но если ты мне покажешь хоть один пример новой технологии (а не расширения/дополнения существующих), где применён ASN.1, за последние 15 лет, я буду удивлён. По-моему, последним героическим движением в эту сторону было H.323.
Открывай любую спецификацию LTE и вот он ASN.1 для всего. Вряд ли там где нужен будет в будущем бинарный и стандартизированный формат передачи данных возьмут что-то другое.
Откройте этот файлик в FAR и замените "something" на "что-то" и сохраните изменения. Теперь попробуйте распарсить этот якобы Xml любым десериализатором. Скорее всего, получите ошибку типа "Invalid character in the given encoding. Line 2, position 14".
Здравствуйте, Kernan, Вы писали:
N>>В старых применениях оно может жить ещё хоть вечно, за компанию к упоминавшемуся тут, не к ночи будь сказано, X12, но если ты мне покажешь хоть один пример новой технологии (а не расширения/дополнения существующих), где применён ASN.1, за последние 15 лет, я буду удивлён. По-моему, последним героическим движением в эту сторону было H.323. K>Открывай любую спецификацию LTE и вот он ASN.1 для всего.
LTE это логически такое же продление GSM, H.323 и прочего ISO'шного голоса, даже если переведено на IP. Поэтому я считаю его расширением существующего, а не новым.
K> Вряд ли там где нужен будет в будущем бинарный и стандартизированный формат передачи данных возьмут что-то другое.
Да вот берут, постоянно. Предпочитают изобретать собственные стандарты (bencode, protocol buffers и тому подобное), gzip-овать XML и JSON, лишь бы к ASN.1 не приближаться. Мне это тоже немного непонятно, чисто практические наблюдения.
N>Да вот берут, постоянно. Предпочитают изобретать собственные стандарты (bencode, protocol buffers и тому подобное), gzip-овать XML и JSON, лишь бы к ASN.1 не приближаться. Мне это тоже немного непонятно, чисто практические наблюдения.
Емнип, ASN.1 сложен для реализации, и в мире существует практически только полтора парсера, поддерживающих его хоть в каком-либо полном объеме. Из известных мне — asn1c и ASN.1 в Эрланге. При том, что и тот и другой используются прямо-таки в промышленных масштабах, и то в обоих автор asn1c недавно нашел баг.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>CSV подходит под нетривиальный парсер? ) А JSON подходит? ) G>>CSV на несколько порядков проще, так как CSV описывается регулярной грамматикой. JSON в этом плане почти также сложен, как XML.
_>JSON почти также сложен, как XML?
Да.
_>>>А зачем писать парсер с нуля?) Естественно надо пользоваться удобными инструментами. О чём и было сказано в моём первом сообщение. G>>Написание парсера с нуля полезно как упражнение на понимание проблем и их решений. Если не понимаешь этих проблем, то вряд ли сделаешь парсер с приемлемой производительностью. _>В качестве обучения конечно же полезно. Но мы тут вроде бы совсем другое обсуждаем...
Мы тут обсуждаем "быстрые и простые парсеры", понимание нужно чтобы разбираться какая связь между простотой и скоростью парсера.
G>>Задача парсинга — одна из немногих, которая "в лоб" не решается. Максимум что может написать человек без предварительной подготовки — простой парсер рекурсивного спуска, который довольно слаб или сильно тормозит.
_>А если он возьмёт в руки скажем bison+flex? )))
Ага, и доку на 900кб прочитает (три войны и мира в объеме). Ты думаешь это так просто, взять и написать парсер нетривиального яызка? Даже с тулами? Как минимум про грамматики надо прочитать, понимать что такое лексеры и парсеры, зачем они нужны, уметь отличать LL от LR и от GLR, понимать что такое lookahead.
Здравствуйте, alex_public, Вы писали:
_>Думаю что в подавляющем большинстве обсуждаемых тут случаев (посмотри о чём была речь выше), возможностей парсера на базе спирита более чем хватит.
Более чем хватит для чего? Чтобы хоть как-то заработал конечно хватит. Если для обработки сотен тысяч сериализаций-десериализаций в секунду, то вряд ли.
Здравствуйте, gandjustas, Вы писали:
g> _>Думаю что в подавляющем большинстве обсуждаемых тут случаев (посмотри о чём была речь выше), возможностей парсера на базе спирита более чем хватит.
g> Более чем хватит для чего? Чтобы хоть как-то заработал конечно хватит. Если для обработки сотен тысяч сериализаций-десериализаций в секунду, то вряд ли.
В ветке в основном обсуждалось использование json для конфига и в таком случае(1-2 файла и относительно редкое чтение) куцая грамматика 'на спирите' (если учесть что boost и так используется в проекте) будет не таким уж плохим решением.
Здравствуйте, Dziman, Вы писали:
D>Здравствуйте, gandjustas, Вы писали:
g>> _>Думаю что в подавляющем большинстве обсуждаемых тут случаев (посмотри о чём была речь выше), возможностей парсера на базе спирита более чем хватит.
g>> Более чем хватит для чего? Чтобы хоть как-то заработал конечно хватит. Если для обработки сотен тысяч сериализаций-десериализаций в секунду, то вряд ли.
D>В ветке в основном обсуждалось использование json для конфига и в таком случае(1-2 файла и относительно редкое чтение) куцая грамматика 'на спирите' (если учесть что boost и так используется в проекте) будет не таким уж плохим решением.
Для конфигов это совершенно быссмысленно. Объем кода для парсера будет в разы больше больше, чем суммарный объем кода, который конфиг использует. Поэтому вдвойне важно иметь готовый парсер.
_>Однако если мне потребуется работа с JSON в моём проекте, я не побегу делать парсер на спирите, а возьму готовую библиотечку.
Вот именно. _>Ну а про "несколько строк на спирите" я упомянул в качестве оценки сложности парсера JSON и сомнительности выражения "промышленные парсеры json". )))
Надеюсь, теперь сомненительность выражения развеяна?
S>>И ключ к такой международной кооперации как раз во внятной спеке, на которую мы можем полагаться.
_>Это о чём вообще речь? ) Об api библиотек? Так он же у каждой библиотеки свой...
Речь о том, что мы с производителем библиотеки одинаково понимаем, что такое JSON. Например, оба ожидаем, что duplicate keys запрещены.
Или оба ожидаем, что выигрывает последнее значение. А не так, что я считаю корректным только какое-то одно поведение, а производитель парсера считает, что он волен выбирать поведение по своему вкусу. И вот он в ответ на какую-нибудь жалобу от тех, кому надо коммутировать JSON со скоростью 2GB/sec немножечко меняет внутреннее устройство, и для duplicate keys возврашается первое значение, а не последнее. Потому что он вообще думал, что такого JSONа не бывает, и во всех его тест кейзах ключи уникальны. Так что у него регрессия пролетает на ура, а я огребаю мучительную отладку тикета у удалённого клиента, потому что хрен его пойми, откуда что берётся.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
_>>JSON почти также сложен, как XML? G>Да.
Ты серьёзно? ))) Ну ок... Я тут уже приводил полную грамматику json'a (правда в синтаксисе спирит'а, но это не суть). Можешь привести аналогичное для xml? )
G>>>Задача парсинга — одна из немногих, которая "в лоб" не решается. Максимум что может написать человек без предварительной подготовки — простой парсер рекурсивного спуска, который довольно слаб или сильно тормозит. _>>А если он возьмёт в руки скажем bison+flex? ))) G>Ага, и доку на 900кб прочитает (три войны и мира в объеме). Ты думаешь это так просто, взять и написать парсер нетривиального яызка? Даже с тулами? Как минимум про грамматики надо прочитать, понимать что такое лексеры и парсеры, зачем они нужны, уметь отличать LL от LR и от GLR, понимать что такое lookahead.
Для нетривиального языка конечно (там кстати и bison не особо подходит). Но мы же тут не C или вообще C++ обсуждаем, а простенький JSON...
Здравствуйте, gandjustas, Вы писали:
D>>В ветке в основном обсуждалось использование json для конфига и в таком случае(1-2 файла и относительно редкое чтение) куцая грамматика 'на спирите' (если учесть что boost и так используется в проекте) будет не таким уж плохим решением. G>Для конфигов это совершенно быссмысленно. Объем кода для парсера будет в разы больше больше, чем суммарный объем кода, который конфиг использует. Поэтому вдвойне важно иметь готовый парсер.
Какое в разы больше? ) Я же чуть выше уже показывал пример задания грамматики json'a для спирита. Там короткий элементарный код.
Здравствуйте, Sinclair, Вы писали:
_>>Ну а про "несколько строк на спирите" я упомянул в качестве оценки сложности парсера JSON и сомнительности выражения "промышленные парсеры json". ))) S>Надеюсь, теперь сомненительность выражения развеяна?
Разве что после начала массового применения тех самых json парсеров с SIMD. )
S>>>И ключ к такой международной кооперации как раз во внятной спеке, на которую мы можем полагаться. _>>Это о чём вообще речь? ) Об api библиотек? Так он же у каждой библиотеки свой... S>Речь о том, что мы с производителем библиотеки одинаково понимаем, что такое JSON. Например, оба ожидаем, что duplicate keys запрещены. S>Или оба ожидаем, что выигрывает последнее значение. А не так, что я считаю корректным только какое-то одно поведение, а производитель парсера считает, что он волен выбирать поведение по своему вкусу. И вот он в ответ на какую-нибудь жалобу от тех, кому надо коммутировать JSON со скоростью 2GB/sec немножечко меняет внутреннее устройство, и для duplicate keys возврашается первое значение, а не последнее. Потому что он вообще думал, что такого JSONа не бывает, и во всех его тест кейзах ключи уникальны. Так что у него регрессия пролетает на ура, а я огребаю мучительную отладку тикета у удалённого клиента, потому что хрен его пойми, откуда что берётся.
Ааа, ну это другой вопрос. ) Вообще я помнится видел в каком-то стандарте требование на уникальность ключей в json. Так что если кто-то не соблюдает, то...
Здравствуйте, netch80, Вы писали:
N>Да вот берут, постоянно. Предпочитают изобретать собственные стандарты (bencode, protocol buffers и тому подобное), gzip-овать XML и JSON, лишь бы к ASN.1 не приближаться. Мне это тоже немного непонятно, чисто практические наблюдения.
Насколько мне известно (сам не трогал, сужу с чужих слов и статей) для ASN.1 до сих пор нет нормальных бесплатных инструментов. Для Си вроде(?) что-то есть, для java, C#, python, js и тому подобного — нет, а ведь разработчику потребуется структуры протокола отображать в структуры языка, "простым" использованием сишной библиотеки (которая то ли есть, то ли нет) не обойдешься.
Здравствуйте, Sinclair, Вы писали:
S>Или оба ожидаем, что выигрывает последнее значение. А не так, что я считаю корректным только какое-то одно поведение, а производитель парсера считает, что он волен выбирать поведение по своему вкусу. И вот он в ответ на какую-нибудь жалобу от тех, кому надо коммутировать JSON со скоростью 2GB/sec немножечко меняет внутреннее устройство, и для duplicate keys возвращается первое значение, а не последнее. Потому что он вообще думал, что такого JSONа не бывает, и во всех его тест кейзах ключи уникальны. Так что у него регрессия пролетает на ура, а я огребаю мучительную отладку тикета у удалённого клиента, потому что хрен его пойми, откуда что берётся.
Когда я занимался автоматизацией автосервисов, то одним из направлений было создание парсеров для сайтов-поставщиков очередного клиента. У некоторых сайтов были вебсервисы, у некоторых приходилось просто разбирать страницы.
И как же чудесно были сделаны их "вебсервисы"! WSDL нет, или есть, да кривой, сертификат самоподписанный и просроченный, digest-аутентификация, которая работает по-разному в зависимости от user-agent, слегка кривой SOAP, формируемый слегка кривой их библиотечкой на PHP. При этом, нормальным считалось не вправлять мозги магазину, чтобы они починили свой уебсервис, привели его в соответствие со стандартами, а разбирать то, что есть. Более того, я уверен, что во многих случаях разработчик с той стороны вообще не понял бы, что от него требуют. Слаще морковки они не едали, какой-то автогенерации stub по wsdl в жизни не видели, у них это никогда не работало и для них норма — подкручивать все руками в каждом индивидуальном случае.
JSON — порождение мира веб-разработки. Где всегда что-то не работает, и это считается нормой вещей.
Тут в теме уже успели пнуть WCF, обозвав его "устаревшей технологией". Немного поработав c проектом, где активно использовался asp.net web api на json, и из сайта, и из мобильных клиентов, меня поразило, что вместо вызова какого-то метода с DTO, эти ребята руками собирают post-запрос с параметрами, все это в using, оттуда летят ошибки, в именах параметров — опечатки. Простой вызов вида
_proxy.Method1(object1, object2)
превращается в какую-то лапшу на 30 строк. В WCF такого безобразия не было. Зато json, js, мобильность и bootstrap с ангуляром ("где $%#&ь с хулиганом, да сифилис" (с) Маяковский).
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>JSON почти также сложен, как XML? G>>Да.
_>Ты серьёзно? ))) Ну ок... Я тут уже приводил полную грамматику json'a (правда в синтаксисе спирит'а, но это не суть). Можешь привести аналогичное для xml? )
Сам гуглить не умеешь? http://www.boost.org/doc/libs/1_48_0/libs/spirit/example/qi/mini_xml3.cpp
както вообще не космос.
G>>>>Задача парсинга — одна из немногих, которая "в лоб" не решается. Максимум что может написать человек без предварительной подготовки — простой парсер рекурсивного спуска, который довольно слаб или сильно тормозит.
_>>>А если он возьмёт в руки скажем bison+flex? ))) G>>Ага, и доку на 900кб прочитает (три войны и мира в объеме). Ты думаешь это так просто, взять и написать парсер нетривиального яызка? Даже с тулами? Как минимум про грамматики надо прочитать, понимать что такое лексеры и парсеры, зачем они нужны, уметь отличать LL от LR и от GLR, понимать что такое lookahead.
_>Для нетривиального языка конечно (там кстати и bison не особо подходит). Но мы же тут не C или вообще C++ обсуждаем, а простенький JSON...
См выделенное.
Здравствуйте, alex_public, Вы писали:
_>Какое в разы больше? ) Я же чуть выше уже показывал пример задания грамматики json'a для спирита. Там короткий элементарный код.
Не видел. Опубликуй исходники на github.
Здравствуйте, netch80, Вы писали:
N>В старых применениях оно может жить ещё хоть вечно, за компанию к упоминавшемуся тут, не к ночи будь сказано, X12, но если ты мне покажешь хоть один пример новой технологии (а не расширения/дополнения существующих), где применён ASN.1, за последние 15 лет, я буду удивлён. По-моему, последним героическим движением в эту сторону было H.323.
На ASN.1 основан ISO9506. И хотя сам протокол уже даже окаменелым говном мамонта назвать не получится, внедрение его в энергетике только сейчас пошло полным ходом. См. IEC61850, вторая версия которого по меркам индустрии вышла только сегодня утром после завтрака.
Насколько широко оно распространено? Ну, индустриальные защитные и контрольные приборы для подстанций уже практически поголовно если не поддерживают его из коробки, то имеют версию или прошивку с этим протоколом, на худой конец адаптер. Скорее всего, многие бытовые электросчетчики тоже скоро будут поддеживать этот протокол, по крайней мере для smart grids.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, netch80, Вы писали:
N>>Тогда и код на C/Delphi/LISP/etc. — бинарь, а не текстовик.
MD>А где в коде C/Delphi/LISP/etc. используются ссылки на encoding?
MD>Тут речь про другое. Создайте такой Xml-файл: MD>
MD>Парсится? Парсится, успешно.
MD>Откройте этот файлик в FAR и замените "something" на "что-то" и сохраните изменения. Теперь попробуйте распарсить этот якобы Xml любым десериализатором. Скорее всего, получите ошибку типа "Invalid character in the given encoding. Line 2, position 14".
Ну таки проблема скорее всего в том, что при созранении текстового файла ему BOM не добавили, а FAR по умолчанию не UTF-8 исползует.
Т.е. не больше чем обычная проблема кодировок.
Тот же php в живой природе бывает и в koi-8 и в 1251 и в utf-8, но там все понимают, что это encoding и никто сорсы бинарями не называет.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Kolesiki, Вы писали: K>>Но в чём прекрасен JSON, так это в удобстве
S>Ну так сценарии использования у них разные, чего смешивать-то?
Какие сценарии? всё та же древняя проблема "передать данные неизвестно куда, но чтобы их поняли".
S>Как показывает практика, на более-менее сложных структурах json откровенно сливает.
Что такое "сложные структуры" и каким образом "сливает"? Что такого немыслимого можно сериализовать, чтобы не уложилось в JSON?
S>И по удобству редактирования...
Нет никакого "редактирования" — "это всё фантастика!". В жизни не видел чудаков, создающих JSON с нуля. Ну а влезть раз в сто лет и поправить структуру — бывало и не составляло НИКАКИХ трудностей, благо редатор умеет даже схлопывать структуры.
S>...и по объёму выигрыш редко превышает 20%
Ну так в XML каждый тег продублирован — это автоматом даёт в JSON более компактный выхлоп! Что тут рассуждать о процентах? Это вопрос принципа: не создавать избыточных данных, сохраняя читабельность.
S> и отсутствие комментов/дат тоже радости не добавляет.
Пофиг. Сериализация придумана ДЛЯ КОМПЬЮТЕРА, но как бонус отладки — текстовый формат, который можно прочитать без спец-редакторов. Комментарии должны быть В КОДЕ — у десериализуемой структуры можно пометить что где означает, зачем их (комменты) дублировать ещё и в сериализованном тексте??
S>Чтоб далеко не ходить: xml, json. На переносы строк в json внимания не обращаем — я их для читабельности оставил. Без них вообще каша получается.
Ну вот! Что непонятного-то? JSON очевидно удобнее — видны названия и значения, всё сгруппировано (вместо XML-мешанины — хрен поймёшь куда там затесался < ). Просто сам формат проекта в студии бестолковый — ты пытаешься понять семантику, хотя речь идёт о читабельности в целом.
Здравствуйте, gandjustas, Вы писали:
_>>Ты серьёзно? ))) Ну ок... Я тут уже приводил полную грамматику json'a (правда в синтаксисе спирит'а, но это не суть). Можешь привести аналогичное для xml? ) G>Сам гуглить не умеешь? http://www.boost.org/doc/libs/1_48_0/libs/spirit/example/qi/mini_xml3.cpp G>както вообще не космос.
Это не XML, а его маленькое простенькое подмножество.
G>>>>>Задача парсинга — одна из немногих, которая "в лоб" не решается. Максимум что может написать человек без предварительной подготовки — простой парсер рекурсивного спуска, который довольно слаб или сильно тормозит. G>_>>>А если он возьмёт в руки скажем bison+flex? ))) G>>>Ага, и доку на 900кб прочитает (три войны и мира в объеме). Ты думаешь это так просто, взять и написать парсер нетривиального яызка? Даже с тулами? Как минимум про грамматики надо прочитать, понимать что такое лексеры и парсеры, зачем они нужны, уметь отличать LL от LR и от GLR, понимать что такое lookahead. _>>Для нетривиального языка конечно (там кстати и bison не особо подходит). Но мы же тут не C или вообще C++ обсуждаем, а простенький JSON... G>См выделенное.
Т.е. по твоему парсер языка уровня json написанный неподготовленным человеком с помощью таких инструментов как boost.spirit или bison+flex обязательно будет сильно тормозить? )
Здравствуйте, gandjustas, Вы писали:
_>>Какое в разы больше? ) Я же чуть выше уже показывал пример задания грамматики json'a для спирита. Там короткий элементарный код. G>Не видел. Опубликуй исходники на github.
Здравствуйте, Mr.Delphist, Вы писали:
N>>Тогда и код на C/Delphi/LISP/etc. — бинарь, а не текстовик.
MD>А где в коде C/Delphi/LISP/etc. используются ссылки на encoding?
В Python есть. Но наличие текстового encoding как раз и означает текст.
MD>Тут речь про другое. Создайте такой Xml-файл: MD>
MD>Парсится? Парсится, успешно.
MD>Откройте этот файлик в FAR и замените "something" на "что-то" и сохраните изменения. Теперь попробуйте распарсить этот якобы Xml любым десериализатором. Скорее всего, получите ошибку типа "Invalid character in the given encoding. Line 2, position 14".
Объясни, пожалуйста. Стандартный парсер умирает на utf-8 без схемы?
Здравствуйте, Kolesiki, Вы писали:
K>Нет никакого "редактирования" — "это всё фантастика!". В жизни не видел чудаков, создающих JSON с нуля.
Сплошь и рядом, и никакого чудачества. Кто-то же должен был эти структуры впервые создать?
А проверять свои интерфейсные модули на чём?
K>Ну так в XML каждый тег продублирован — это автоматом даёт в JSON более компактный выхлоп! Что тут рассуждать о процентах? Это вопрос принципа: не создавать избыточных данных, сохраняя читабельность.
Как раз наличие именованного закрывающего тега повышает читабельность сложных структур, в отличие от простой "}" без возможности комментировать.
S>> и отсутствие комментов/дат тоже радости не добавляет. K>Пофиг. Сериализация придумана ДЛЯ КОМПЬЮТЕРА, но как бонус отладки — текстовый формат, который можно прочитать без спец-редакторов. Комментарии должны быть В КОДЕ — у десериализуемой структуры можно пометить что где означает, зачем их (комменты) дублировать ещё и в сериализованном тексте??
Затем, что там, где структура используется как часть _конфига_ для человека, крайне полезна возможность комментировать. Конфиг — он, знаешь ли, руками пишется, правится, какие-то части могут быть временно выключены, часто в штатных комментариях идут примеры, как писать (чтобы не лезть далеко в документацию).
K>Ну вот! Что непонятного-то? JSON очевидно удобнее — видны названия и значения, всё сгруппировано (вместо XML-мешанины — хрен поймёшь куда там затесался < ).
Здравствуйте, mtnl, Вы писали:
MD>>Откройте этот файлик в FAR и замените "something" на "что-то" и сохраните изменения. Теперь попробуйте распарсить этот якобы Xml любым десериализатором. Скорее всего, получите ошибку типа "Invalid character in the given encoding. Line 2, position 14". M>Ну таки проблема скорее всего в том, что при созранении текстового файла ему BOM не добавили, а FAR по умолчанию не UTF-8 исползует.
У меня в обстановке (Ubuntu, FreeBSD) utf-8 по умолчанию. Пробовал через xml.parsers.expat от Python 3.4. Да, если BOM нет, то без явного указания utf-8 при создании объекта парсера оно такое не понимает, вылетает с руганью. Увидев BOM — понимает само. Посмотрел на реальный конфиг (~/.purple/blist.xml) — там BOM нет, но парсер понимает (важен другой парсер в libpurple, или ему заранее задают кодировку?)
M>Т.е. не больше чем обычная проблема кодировок. M>Тот же php в живой природе бывает и в koi-8 и в 1251 и в utf-8, но там все понимают, что это encoding и никто сорсы бинарями не называет.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, netch80, Вы писали:
N>>В старых применениях оно может жить ещё хоть вечно, за компанию к упоминавшемуся тут, не к ночи будь сказано, X12, но если ты мне покажешь хоть один пример новой технологии (а не расширения/дополнения существующих), где применён ASN.1, за последние 15 лет, я буду удивлён. По-моему, последним героическим движением в эту сторону было H.323.
L>На ASN.1 основан ISO9506. И хотя сам протокол уже даже окаменелым говном мамонта назвать не получится, внедрение его в энергетике только сейчас пошло полным ходом. См. IEC61850, вторая версия которого по меркам индустрии вышла только сегодня утром после завтрака.
Только подтверждает мою оценку.
L>Насколько широко оно распространено? Ну, индустриальные защитные и контрольные приборы для подстанций уже практически поголовно если не поддерживают его из коробки, то имеют версию или прошивку с этим протоколом, на худой конец адаптер. Скорее всего, многие бытовые электросчетчики тоже скоро будут поддеживать этот протокол, по крайней мере для smart grids.
Здравствуйте, alex_public, Вы писали:
_>Ааа, ну это другой вопрос. ) Вообще я помнится видел в каком-то стандарте требование на уникальность ключей в json. Так что если кто-то не соблюдает, то...
Это не другой вопрос. Это вопрос (см. http://rsdn.ru/forum/flame.comp/6253172.1
Здравствуйте, alex_public, Вы писали:
_>Ну на сайте того же Parabix есть упоминание только о реализации grep в качестве примера их технологии. Понятно, что json парсер даже проще, так что задача вполне выполнима. Но и её кто-то должен сделать, что совсем не тривиально с учётом особенностей данного подхода. Так что подождём ответа Cyberax'а с деталями.
Я просто взял статью о Parabix'е и сделал как там написано. Руками на бумажке выписал все возможные комбинации событий и сделал парсер. Где-то через неделю оно даже заработало.
Статью о Parabix'е кто-то (я?) засылал сюда ещё году так в 2005-м, вот где-то год назад она пригодилась.
Здравствуйте, Sinclair, Вы писали:
_>>Про использование SIMD для текстовых парсеров я действительно был не в курсе, признаю. Правда я вот очень сомневаюсь, что данная хитрая технология применяется в каком-то из так называемых "промышленных" парсеров json. S>Пока — нет. Но те, кто выбирает "три строки на спирите" для таких вещей, гарантированно отрезают себя от передовых достижений.
Так а смысл от них? Даже самый тормозной парсер на Спирите будет работать с достаточной скоростью для разбора гигабитного потока. Причём вполне корректно.
Понятно, что обычно проще использовать библиотеки. Особенно учитывая, что результат разбора JSON в большинстве языков выдаёт обычные стандартные структуры данных. С XML была вечная проблема с тем, что одной библиотеке нужна Dom4J, другой Java DOM, а третей вообще JDOM.
Здравствуйте, Sinclair, Вы писали:
S>Или оба ожидаем, что выигрывает последнее значение. А не так, что я считаю корректным только какое-то одно поведение, а производитель парсера считает, что он волен выбирать поведение по своему вкусу. И вот он в ответ на какую-нибудь жалобу от тех, кому надо коммутировать JSON со скоростью 2GB/sec немножечко меняет внутреннее устройство, и для duplicate keys возврашается первое значение, а не последнее.
По факту, в JSON два правильных поведения: "кто последний тот и папа" или ошибка парсера. Есть ещё разное поведение, если корневой элемент — это массив, а не объект (формально это запрещено, но на практике многие допускают). Ну и как бы всё.
По сложности с XML несравнимо, за счёт чего и рулит.
Здравствуйте, gandjustas, Вы писали:
_>>Ты серьёзно? ))) Ну ок... Я тут уже приводил полную грамматику json'a (правда в синтаксисе спирит'а, но это не суть). Можешь привести аналогичное для xml? ) G>Сам гуглить не умеешь? http://www.boost.org/doc/libs/1_48_0/libs/spirit/example/qi/mini_xml3.cpp G>както вообще не космос.
Это вот только совсем не XML. Разрешения namespace'ов нет, DTD нету, кодировки не поддерживаются, валидация имён неправильная и т.д.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Mr.Delphist, Вы писали:
N>>>Тогда и код на C/Delphi/LISP/etc. — бинарь, а не текстовик.
MD>>А где в коде C/Delphi/LISP/etc. используются ссылки на encoding?
N>В Python есть. Но наличие текстового encoding как раз и означает текст.
MD>>Тут речь про другое. Создайте такой Xml-файл: MD>>
MD>>Парсится? Парсится, успешно.
MD>>Откройте этот файлик в FAR и замените "something" на "что-то" и сохраните изменения. Теперь попробуйте распарсить этот якобы Xml любым десериализатором. Скорее всего, получите ошибку типа "Invalid character in the given encoding. Line 2, position 14".
N>Объясни, пожалуйста. Стандартный парсер умирает на utf-8 без схемы?
Просто FAR сохраняет не в UTF-8, а либо в однобайтный CP-1251, либо в двухбайтный UTF-16. Парсер находит несоответствие метаданных и контента и выдаёт честное "не шмогла".
Здравствуйте, Mr.Delphist, Вы писали:
MD>>><?xml version="1.0" encoding="UTF-8"?> MD>>><root value="something" /> MD>>>Откройте этот файлик в FAR и замените "something" на "что-то" и сохраните изменения. Теперь попробуйте распарсить этот якобы Xml любым десериализатором. Скорее всего, получите ошибку типа "Invalid character in the given encoding. Line 2, position 14". N>>Объясни, пожалуйста. Стандартный парсер умирает на utf-8 без схемы? MD>Просто FAR сохраняет не в UTF-8, а либо в однобайтный CP-1251, либо в двухбайтный UTF-16. Парсер находит несоответствие метаданных и контента и выдаёт честное "не шмогла".
Не всё так просто. Если я сделаю такой же эксперимент на своей системе (у меня только юниксы, возьмём для примера Ubuntu), там utf-8. Парсер — expat из Питона (ничего проще не нашёл). Парсер со всеми опциями по умолчанию и на файле в utf-8 без BOM мрёт точно так же. Если поставить BOM и/или сказать при создании парсера, чтобы читал в utf-8 — читается без проблем.
Не думаю, что это их самодеятельность. Скорее, режим работы стандартизован на какой-нибудь тупой дефолт типа iso-8859-1.
Здравствуйте, Cyberax, Вы писали:
C>По факту, в JSON два правильных поведения: "кто последний тот и папа" или ошибка парсера. Есть ещё разное поведение, если корневой элемент — это массив, а не объект (формально это запрещено, но на практике многие допускают). Ну и как бы всё.
Все до сих пор встреченные мной JSON парсеры допускали, что корень — что угодно, включая варианты 3.1415926535 или null.
Думаю, это ориентация на вебовую специфику.
Но это таки не усложняет парсер, по крайней мере, если его явно не усложнять
Здравствуйте, flаt, Вы писали:
F>Оказывается, в SQLite тоже прикрутили JSON не так давно.
Лучше они бы ALTER TABLE докрутили, наконец. Добавить колонку в таблицу — пожалуйста, а дропнуть её — фига с маслом. В качестве work-around предлагается пересоздать таблицу и вкачать в неё старые данные за минусом ненужной колонки
Здравствуйте, Sinclair, Вы писали:
_>>Ааа, ну это другой вопрос. ) Вообще я помнится видел в каком-то стандарте требование на уникальность ключей в json. Так что если кто-то не соблюдает, то... S>Это не другой вопрос. Это вопрос (см. http://rsdn.ru/forum/flame.comp/6253172.1
В обсуждение этого вопроса я бы разделил применение JSON на две совершенно разные области:
1. Хранение информации в рамках одной системы
2. Передача информации между разными системами.
Очевидно, что в первом случае никаких особых проблем быть не может, т.к. для сериализации/десериализации применяется один и тот же движок (который естественно самосогласованный).
Во втором случае (это обычно взаимодействие каких-то веб-сервисов и т.п.) при нечёткой спецификации формата конечно возможны какие-то проблемы. Но это вообще довольно проблемная задача, которую в любом случае отлаживают руками.
Здравствуйте, Cyberax, Вы писали:
_>>Ну на сайте того же Parabix есть упоминание только о реализации grep в качестве примера их технологии. Понятно, что json парсер даже проще, так что задача вполне выполнима. Но и её кто-то должен сделать, что совсем не тривиально с учётом особенностей данного подхода. Так что подождём ответа Cyberax'а с деталями. C>Я просто взял статью о Parabix'е и сделал как там написано. Руками на бумажке выписал все возможные комбинации событий и сделал парсер. Где-то через неделю оно даже заработало.
Здорово, серьёзная работа. Не было желания оформить это в виде публичной библиотеки? )
Здравствуйте, alex_public, Вы писали:
C>>Я просто взял статью о Parabix'е и сделал как там написано. Руками на бумажке выписал все возможные комбинации событий и сделал парсер. Где-то через неделю оно даже заработало. _>Здорово, серьёзная работа. Не было желания оформить это в виде публичной библиотеки? )
Давно хочу, как только одобрит юротдел — попробую открыть.
Здравствуйте, netch80, Вы писали:
L>>На ASN.1 основан ISO9506. И хотя сам протокол уже даже окаменелым говном мамонта назвать не получится, внедрение его в энергетике только сейчас пошло полным ходом. См. IEC61850, вторая версия которого по меркам индустрии вышла только сегодня утром после завтрака.
N>Только подтверждает мою оценку.
Здравствуйте, netch80, Вы писали:
N>LTE это логически такое же продление GSM, H.323 и прочего ISO'шного голоса, даже если переведено на IP. Поэтому я считаю его расширением существующего, а не новым.
Нет. Радио часть очень сильно поменялась. Теперь там есть гибкое выделение радиоресурсов под пользователя, полностью дата-ориентированность без всяких тебе там выделенных полос под голосовой трафик. От GSM и H.323 оно ушло очень далеко. N>Да вот берут, постоянно. Предпочитают изобретать собственные стандарты (bencode, protocol buffers и тому подобное), gzip-овать XML и JSON, лишь бы к ASN.1 не приближаться. Мне это тоже немного непонятно, чисто практические наблюдения.
Потому что задачи примитивные и объёмы трафика небольшие, при этом у них нет требований к ресурсам канала. Не хватает канала? Бросим ещё оптоволокна, больше оптоволокна для передачи XML/JSON., С радиоканалом это не пройдёт, дадут тебе 5 или 1.4 MHz и крутись как хочешь.
Здравствуйте, Cyberax, Вы писали:
_>>Здорово, серьёзная работа. Не было желания оформить это в виде публичной библиотеки? ) C>Давно хочу, как только одобрит юротдел — попробую открыть.
Дома надо эксперементировать
Здравствуйте, Sheridan, Вы писали:
S> _>>Здорово, серьёзная работа. Не было желания оформить это в виде публичной библиотеки? ) S> C>Давно хочу, как только одобрит юротдел — попробую открыть. S> Дома надо эксперементировать
Зачем, если можно на рабочем месте за деньги?
Здравствуйте, Dziman, Вы писали:
S>> _>>Здорово, серьёзная работа. Не было желания оформить это в виде публичной библиотеки? ) S>> C>Давно хочу, как только одобрит юротдел — попробую открыть. S>> Дома надо эксперементировать D>Зачем, если можно на рабочем месте за деньги?
А, ты всего лишь профессионал
Здравствуйте, Sheridan, Вы писали:
S>>> Дома надо эксперементировать D>>Зачем, если можно на рабочем месте за деньги? S>А, ты всего лишь профессионал
Ты всегда все эксперименты ставишь только дома и бесплатно? Завидую. Меня жена давно бы выставила из дому. Ну правда, на кой ей муж, который дома ей предпочитает компьютерные изыскания и из сервантов делает компьютерную технику.
И вообще, ты так говоришь, как будто профессионал — это что-то плохое.
Здравствуйте, Privalov, Вы писали:
S>>>> Дома надо эксперементировать D>>>Зачем, если можно на рабочем месте за деньги? S>>А, ты всего лишь профессионал
P>Ты всегда все эксперименты ставишь только дома и бесплатно? Завидую. Меня жена давно бы выставила из дому. Ну правда, на кой ей муж, который дома ей предпочитает компьютерные изыскания и из сервантов делает компьютерную технику.
Моя такая-же как я, только в другой, не-it области. Тоже дома частенько работает и на работе допоздна задерживается.
P>И вообще, ты так говоришь, как будто профессионал — это что-то плохое.
В данном случае, а именно "Зачем, если можно на рабочем месте за деньги?" — да. Человеку неинтересна его работа, он в ней видит только средство заработать знаки. Зачем так жить? Надо искать то, что интересно, чем хочется заниматься безотносительно оплаты. Деньги должны стоять на втором, а то и на третьем-четвертом местах.
Здравствуйте, Sheridan, Вы писали:
S>Моя такая-же как я, только в другой, не-it области. Тоже дома частенько работает и на работе допоздна задерживается.
Тут я мог бы к формулировке придраться, ну да ладно.
S>В данном случае, а именно "Зачем, если можно на рабочем месте за деньги?" — да. Человеку неинтересна его работа, он в ней видит только средство заработать знаки. Зачем так жить? Надо искать то, что интересно, чем хочется заниматься безотносительно оплаты. Деньги должны стоять на втором, а то и на третьем-четвертом местах.
А если у него, кроме жены, маленькие дети? А может, не очень маленькие.
Я когда-то мог по двое суток с работы не вылезать. Даже время на сон жалко было тратить. Все же приходилось на час-другой делать перерыв и засыпать на стульях. А сейчас я если чем и могу гордиться, то не этим, а что мои дети знают об отце не только, что он существует и даже иногда бывает дома.
Здравствуйте, Privalov, Вы писали:
P>А если у него, кроме жены, маленькие дети? А может, не очень маленькие. P>Я когда-то мог по двое суток с работы не вылезать. Даже время на сон жалко было тратить. Все же приходилось на час-другой делать перерыв и засыпать на стульях. А сейчас я если чем и могу гордиться, то не этим, а что мои дети знают об отце не только, что он существует и даже иногда бывает дома.
А никто и не говорит, что критически необходимо заниматься любимым делом 24х7
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Sheridan, Вы писали:
S>>А никто и не говорит, что критически необходимо заниматься любимым делом 24х7
P>На работе надо работать, дома — экспериментировать
.
Ок, ради булевых программистов буду теперь дописывать "было бы лучше и интереснее". А то для этих булевых погроммистов мир исключительно либо чоорный либо белый, ага.
Здравствуйте, Нахлобуч, Вы писали:
Н>Вот что это за непотребство такое? Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?
Если вы говорите конкретно об ASP.NET 5, то не переживайте — он не взлетит. Его сейчас пилят неламповые хипстеры в розовых очках, поэтому результат гарантирован: засохший круассан, который хочет быть и пирожком, и шашлыком, а в реальности не может быть даже съеден.
Здравствуйте, vsb, Вы писали:
vsb>Это называется мода.
Я бы не сказал, что это мода. Это типичная ситуация, когда некоторые программисты, как я понимаю, вроде тебя, потратили N человеко-месяцев на изучение многих возможностей XML, и научились его готовить. А другая часть, вроде меня, пожалели на это время. Ну и когда распространился JSON, который можно выучить за пару часов, и который покрывает 99% их потребностей, начали его использовать.
Хотя не, вру, шутка удалась. Юмор в следующем:
1. Изменения будут после RC2.
2.
.NET Core and ASP.NET Core 1.0 RTM (release) runtime and libraries will be available by the end of June.
...
The .NET Core 1.0 RC2 runtime is a true Release Candidate. It’s solid, stable, and it won’t change for RTM (except if something critical happens) and we feel good about it. It will have a “go-live” license, meaning you can get official support from Microsoft.
Здравствуйте, Sinix, Вы писали:
S>Эпическое раздолбайство, как по мне. По сравнению с ним прежние подвиги типа breaking changes в inplace-обновлениях фреймворка вообще не смотрятся.
Хипстеры бушуют: csproj, xproj, JSON, YAML, TOML, XML Sucks, nuget.json...
Здравствуйте, 0BD11A0D, Вы писали:
BDA>1.json лучше.
)))
А извраты с "_Condition" и "__text": совсам-совсем не смущают? В общем, вам вот сюда.
На практике json хорош только для стартап-стайл, когда проект — это просто папочка с исходниками + списком зависимостей.
Для сложных проектов, с reusable parts, таргетингом, conditional references, conditional includes, pre&post-build actions и прочими радостями энтерпрайза городить что-то на json — как с перочинным ножиком на медведя. Несерёзно от слова совсем.
Про "как быстро отключить секцию проекта" даже не будем, совсем троллинг получается.
Ясен перец, когда простого ответа на простой вопрос нет, а есть такие статьи, вопрос совсем не прост. У меня, конечно, есть свой интуитивный ответ (я хорошо чувствую разницу между случаями, когда свойство важнее как сущность или, все-таки, как свойство), но:
0. Свой опыт другому не передашь, иначе как написав очередную длинную статью, которую никто читать не будет.
1. Много программистов юзает какой-нибудь SAX-парсер и хер забивает на свойства как таковые по преченческим технинам. Особенно, C++ и прочий олдскул.
2. Смесь аттрибутов и значений в тегах плохо ложится на SQL, который не видит разницы между метаданными объекта и просто данными. В смысле, без создания дополнительной таблицы.
В итоге, прагматичные люди давно забили на аттрибуты. В принципе. Мешают все прямо с данными. В json этот принцип узаконили и положили конец аттрибутосрачу, как один Саша Гордиевой веревке. Решение не идеальное (идеально было бы усовершенствовать SQL, отказаться от тупых парсеров и языков, вырвать все руки из всех жоп, а потом наслаждаться... нет, не XML, а каким-нибудь JSON+ с аттрибутами), но в нашем мире, возможно, лучшее.
Если не выделять префиксами бывшие аттрибуты (по принципу «в новом паспорте отменить графу 'Национальность' и ввести графу 'Какая национальность была до отмены'»), а переписать код студии так, чтобы, разница стерлась, то и извраты будут не нужны.
S>На практике json хорош только для стартап-стайл, когда проект — это просто папочка с исходниками + списком зависимостей.
Если посчитать, сколько в мире вполне себе коммерчески состоявшихся веб-сайтов с AJAX и сколько — программ с конфигами, вы с вашим утверждением будете иметь весьма бледный вид. И тренд таков, что последних будет все меньше, а первых — все больше.
S>Для сложных проектов, с reusable parts, таргетингом, conditional references, conditional includes, pre&post-build actions и прочими радостями энтерпрайза
Следовало бы написать — «...и прочей архитектурной астронавтикой». Для начала, reusable parts — это миф, основанный на мании величия программистов и стремлении оставить свое гавноподелие на века. В девяти случаях из десяти в реальной жизни на проекте есть склад трудноклассифицируемого кода, который отправляют в Utils или Helpers, потому, что ума не хватает организовать структуру без этой мешанины. Потом, когда критическая масса дерьма набрана, это начинают гордо называть 'reusable parts', при том, что перетащить в новый проект — уже проблема (то зависимости не дают, то проект от этой reusable part разбухает, то просто люди рады, что можно вместо вызова этого корявства написать в несколько строчек). Это в жизни так, а не в вашей стране розовых фей.
Единственные немифические reusable parts, это библиотеки и API. И знаете что? Самый библиотечный язык и платформа в мире (вспомните алкоигру, когда придумываешь слово, добавляешь .js, гуглишь, находишь библиотеку или фреймворк и выпиваешь рюмку) весь обмазан этим json'ом начиная от конфига из репо и заканчивая протоколами библиотек.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Аттрибуты в XML меня смущают гораздо больше. Я имею в виду вот этот древний срач: http://www.ibm.com/developerworks/xml/library/x-eleatt/index.html BDA>Ясен перец, когда простого ответа на простой вопрос нет, а есть такие статьи, вопрос совсем не прост.
Вопрос как раз прост и проблема не в нём. Основные правила прямо в древнесраче расписаны, остальной текст — сплошь страдания на тему "ах, но что же делать, если выбор не очевиден?".
Проблема в товарищах, которые берутся менять инфраструктуру без предварительного изучения матчасти.
Как правило это заканчивается эпичным фейлом с злостной раздачей трындюлей причастным и непричастным, ибо не остановили. Что мы и наблюдаем на наглядном примере.
Ибо два года страдать %censored%, а затем заметить, что упс, у нас внезапно проблемы с портированием real-world проектов — это эльфизм 9k. Хипстеры, как и было сказано
BDA>В итоге, прагматичные люди давно забили на аттрибуты. В принципе. Мешают все прямо с данными
Прагматичные люди следуют правилу "если инструмент сломан — возьми нормальный". И используют нормальный тулчайн, от парсеров и до СУБД.
В первый раз слышу, чтобы от атрибутов отказывались по причине "мы их не осилили"
BDA>Если не выделять префиксами бывшие аттрибуты (по принципу «в новом паспорте отменить графу 'Национальность' и ввести графу 'Какая национальность была до отмены'»), а переписать код студии так, чтобы, разница стерлась, то и извраты будут не нужны.
Угу, а идейки куда девать прикажете(с)?
Ну, т.е. что использовать для ситуаций, когда нужны были именно атрибуты, как с Conditional?
BDA>Если посчитать, сколько в мире вполне себе коммерчески состоявшихся веб-сайтов с AJAX и сколько — программ с конфигами, вы с вашим утверждением будете иметь весьма бледный вид. И тренд таков, что последних будет все меньше, а первых — все больше.
Угу-угу. Нам тут в прямом эфире показывают, как реальные клиенты дружно голосуют за json вместо csproj Кэп: в последний момент такие правки вносятся только после очень волшебного пенделя.
BDA>Для начала, reusable parts — это миф, основанный на мании величия программистов и стремлении оставить свое гавноподелие на века.
Контекст потеряли. Мы внутренности msbuild project system обсуждаем. Какие нафиг библиотеки?
Для msbuild reusable parts — это <Import> + .targets-файлы. На них построено много чего полезного, в том числе 99% любых нетривиальных билд-процессов.
Здравствуйте, Sinix, Вы писали:
S>Прагматичные люди следуют правилу "если инструмент сломан — возьми нормальный".
А если пользователь сломан? Тоже «возьми нормальный»? Я не фантазирую, а просто вспоминаю, как группа приплюсников просила избавиться от разделения на аттрибуты и ноды. И, кстати, я даже не уверен, что они были не правы. Язык и обвязку у них диктовала платформа, а парсеров на них был (в те времена) далеко не избыток. Что надо было другое взять? Заказчика? Или уже сразу деньги свои напечатать?
S>В первый раз слышу, чтобы от атрибутов отказывались по причине "мы их не осилили"
А может, кстати, наоборот — они просили в аттрибуты все данные перекинуть, из нод. Я уже не помню. Помню, что поддерживать и то, и другое им было неудобно.
Сути дела это не меняет: в XML есть разделение на данные и метаданные, в json нет.
BDA>>Если не выделять префиксами бывшие аттрибуты (по принципу «в новом паспорте отменить графу 'Национальность' и ввести графу 'Какая национальность была до отмены'»), а переписать код студии так, чтобы, разница стерлась, то и извраты будут не нужны. S>Угу, а идейки куда девать прикажете(с)? S>Ну, т.е. что использовать для ситуаций, когда нужны были именно атрибуты, как с Conditional?
Как что? Информацию о том, когда объект применяется, записать в сам объект. То есть, описывая конфигурацию в описании указывать — применимо для того-сего. Инженерно не очень, зато в главной струе.
S>Угу-угу. Нам тут в прямом эфире показывают, как реальные клиенты дружно голосуют за json вместо csproj Кэп: в последний момент такие правки вносятся только после очень волшебного пенделя.
А, это просто издержки фирменного стиля Майкрософт при лысом и индусе.
Была у них такая система — Windows Mobile. Они тянули-тянули, ничего не улучшая, API был сырой, настройки сетей — недружелюбные, производителей железа не пинали, и т.д. и т.п. Хуже того, когда айфон вышел, они объявили, что платформа не взлетит. Потом внезапно осознали, и опять же внезапно все поперехерачили. На тот момент, когда они впервые вслух похоронили ОС, у них было, как мне помнится, 30% рынка. Теперь 1.
Значит ли это, что с выходом айфона надо было ВООБЩЕ НИЧЕГО НЕ МЕНЯТЬ? Ну, они пришли бы к 2016 году с тем же результатом — 1 процент — но просто постепенно.
Что надо было, это пользуясь своей долей, плавно переводить юзеров на новые рельсы, а не устраивать свои дебильные нежданчики. Первым делом — мультитач прикрутить, затем — дотировать мануфактурерам застекление и разрешение, затем — you name it. И, наверное, придти, в конце концов, к тому же, к чему они все пришли (и Гандроид, и Ябл). Только иметь в кармане не босый хер и операционку в виде чемодана без ручки, а свою долю рынка, измеряемую десятками процентов.
Понимаете, к чему я веду? Реальные клиенты их давно линяют по другим платформам. Эволюция идет с неизбежностью ледника. Переходи они на json или не переходи, рано или поздно кранты ихнему ASP. И они это понимают. Студия 2015, ИМХО, интересна только потому, что Node.JS поддерживает из коробки, вместе с редактором клиентских скриптов. А к ней они какие-то свои сервисики приделывают, то есть, ищут новые рынки. Все как с айфоном и WP, вплоть до того, что на старых, традиционных реальных клиентов, представляющих исчезающий рынок, демонстративно забивают болт (не успев завоевать новых высот). О чем эти клиенты потом верещат в прямом эфире (как я верещал, когда они меня прокинули с WM).
Не надо было, конечно, им этого делать. Но не потому, что у старья (XML, ASP) есть будущее, а потому, что перегонять стадо из загона в загон надо ловчее.
BDA>>Для начала, reusable parts — это миф, основанный на мании величия программистов и стремлении оставить свое гавноподелие на века. S>Контекст потеряли. Мы внутренности msbuild project system обсуждаем. Какие нафиг библиотеки? S>Для msbuild reusable parts — это <Import> + .targets-файлы. На них построено много чего полезного, в том числе 99% любых нетривиальных билд-процессов.
Если мы говорим только об msbuild, пока еще не перевелись люди, которые им пользуются, я б их злить не стал.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Нахлобуч, Вы писали:
Н>>Вот что это за непотребство такое? S>Ну имхо json это самый удобный вариант для конфигов. Категорически прост, древовиден, структуризован, типизирован и не так наворочен, как xml.
Если считать только эти пункты — то чем он лучше YAML?
S>По личному опыту: xml трудно читать, количество скобок превышает все мыслимые пределы, закрывающие теги только мешают
При том что именно читать YAML удобней чем все другие форматы.
BDA>А если пользователь сломан? Тоже «возьми нормальный»? Я не фантазирую, а просто вспоминаю, как группа приплюсников просила избавиться от разделения на аттрибуты и ноды. И
Ну по-хорошему да. В смысле, не пользователя менять, а подход. Или просить заказчика предоставить xsd-схему (это заодно решает 1000 других вопросов), или не притворяться, что у вас валидный xml.
BDA>Как что? Информацию о том, когда объект применяется, записать в сам объект. То есть, описывая конфигурацию в описании указывать — применимо для того-сего. Инженерно не очень, зато в главной струе.
Ну так косяк это. Для любого графа характерны конструкции вида узел с кучей атрибутов + подузлы. На xml такие конструкции ложатся как родные. В json зачастую приходится городить отдельные контейнеры для атрибутов и для подузлов, чтоб не смешивались.
BDA>А, это просто издержки фирменного стиля Майкрософт при лысом и индусе.
Не-не-не, давайте не смешивать аналогии, неверные предположения и реальное положение дел. Расклад такой:
BDA>Была у них такая система — Windows Mobile.
Вот тут 100% менеджмент-фейл, с технической стороны винфон на сегодня — одна из самых изящных платформ. С продвижением ёк, ну так вообще удивительно, что оно вообще продаётся, с таким-то творческим подходом.
BDA>Понимаете, к чему я веду? Реальные клиенты их давно линяют по другим платформам.
А вот тут — фига с два. Просто большинство клиентов плавно переползают с самосбора на решения "допилить напильником". Ну, т.е. в нишу конструкторов сайтов, пхп и 1с
У дотнета тут позиции нулевые, ибо чисто исторически дотнет — это энтерпрайз, всё остальное — бонусом. Смена фокуса во многом следствие потери рынка мобильных девайсов. По сути было принято решение зайти с другой стороны — через своё API и сервисы на всех платформах. И все подвижки в сторону "фигак в блокноте и в продакшн" — именно следствие, не более. Так что фейл, но фейл закономерный, из разряда первый блин комом. Вот дальше будет ещё интересней — инерция набрана немалая, тот же json формат может не менее внезапно вернуться в виде стороннего дополнения или в виде штуки, которую будут перегонять в msbuild-файл. Тем более, что все фичи xproj и так в процессе портирования в msbuild engine.
BDA>Эволюция идет с неизбежностью ледника. Переходи они на json или не переходи, рано или поздно кранты ихнему ASP.
И снова нет — куда ж они денутся? Отток возможен только для прослойки "что в дизайн-студии предложили, то и взяли". Это товарищи постоянные, как флюгер, каждые два года фаворит меняется. Легко пришло — легко ушло короче.
BDA>И они это понимают. Студия 2015, ИМХО, интересна только потому, что Node.JS поддерживает из коробки, вместе с редактором клиентских скриптов.
Ну блин, снова вы на следствия смотрите, а не на первопричины. Второй год на конференциях прямым текстом рассказывают что и почему. Они не только ноду поддерживают, они практически всё к себе под крыло сгребают. Вон недавно про .net-стек расписывал
BDA>Не надо было, конечно, им этого делать. Но не потому, что у старья (XML, ASP) есть будущее, а потому, что перегонять стадо из загона в загон надо ловчее.
Ну а вот это снова тёмная сторона MS Которая отвечает за биз-стратегию, а не за техническую реализацию. У них на один успех один фейл приходится, всегда так было.
Понятно, что успешные вещи не запоминаются в отличие от фейлов, особенно свежих. С другой стороны, пользуемся мы именно успешными штуками и с ними я не сказал бы что всё так плохо.
Достаточно в этой схеме появиться ещё одному атрибуту, к примеру, hint path или имени нюгет-фида, как "наглядный" код превращается в кучу отступов и скобочек.
Xml от этой проблемы по понятным причинам не страдает.
UPD: с галёрки подсказывают, что 99% сторонников yaml-а сами yaml не кушали. Одно требование "никаких табов" уже ставит на нём крест, как на языке для человеков.
Нравится зависеть от невидимых символов — велкам в whitespace, в рабочий проект такой изврат тащить точно не стоит.
TOML тож немногим лучше — один таб == один пробел, насколько помню. Может поменялось, давно смотрел.
Здравствуйте, Sinix, Вы писали:
S>TOML тож немногим лучше — один таб == один пробел, насколько помню. Может поменялось, давно смотрел.
TOML:Indentation (tabs and/or spaces) is allowed but not required
Т.е. используется только для визуальной "красоты":
[servers]
# Indentation (tabs and/or spaces) is allowed but not required
[servers.alpha]
ip = "10.0.0.1"
dc = "eqdc10"
[servers.beta]
ip = "10.0.0.2"
dc = "eqdc10"
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
Н>Т.е. используется только для визуальной "красоты":
Ага, фигню написал, спасибо за поправку!
Toml тогда точно смотрится лучше, чем прочие замены xml-ю.
Хотя не, с галёрки снова подсказывают, что в длинных вложенных таблицах нельзя просто так взять и переименовать узел. В общем куда не глянь — везде какой-то косяк
Здравствуйте, Sinix, Вы писали:
BDA>>А если пользователь сломан? Тоже «возьми нормальный»? Я не фантазирую, а просто вспоминаю, как группа приплюсников просила избавиться от разделения на аттрибуты и ноды. И S>Ну по-хорошему да. В смысле, не пользователя менять, а подход. Или просить заказчика предоставить xsd-схему (это заодно решает 1000 других вопросов), или не притворяться, что у вас валидный xml.
Ну, дадут схему, а там одни аттрибуты. Или все в ноды свалено. И что? Если техническая проблема имеет место, схема ее не закроет.
Кроме того, не могу удержаться от вопроса: мы что, кодеры? Или, все-таки, зарабатыватели денег? Просить заказчика об xsd-схеме, когда он сам в ней не заинтересован, это, зачастую, итальянская забастовка. На свободном рынке обструкционизм несовместим с заработками. Может, еще функциональную спецификацию просить?
BDA>>Как что? Информацию о том, когда объект применяется, записать в сам объект. То есть, описывая конфигурацию в описании указывать — применимо для того-сего. Инженерно не очень, зато в главной струе. S>Ну так косяк это. Для любого графа характерны конструкции вида узел с кучей атрибутов + подузлы. На xml такие конструкции ложатся как родные. В json зачастую приходится городить отдельные контейнеры для атрибутов и для подузлов, чтоб не смешивались.
Я, собственно, перечислил все «зато»:
1. Зато такой XML, в свою очередь, плохо ложится на SQL;
2. Зато правильно писать такой XML труднее;
3. Зато (были?) проблемы с парсингом.
Разумеется, (1) мало кто будет класть в SQL *proj и как-нибудь в MS осилят теорию (2) и практику (3). (Это к вопросу о контексте). Я про более общую постановку вопроса, а именно: да, нельзя без потерь информации отконвертировать произвольный XML в json, т.е. XML универсальнее. Но с учетом практики применения XML, это не так уж важно.
Более того, если не грузиться специально, что condition — метаданные, в файле 1.json это в глаза не бросается, а в остальном он гораздо человекочитаемее.
S>
BDA>>А, это просто издержки фирменного стиля Майкрософт при лысом и индусе. S>Не-не-не, давайте не смешивать аналогии, неверные предположения и реальное положение дел.
Любая метафора имеет свои ограничения. Для меня важно, что Майкрософт в погоне за новыми рынками забивает на текущую клиентуру. Что мы тут и видим в прямом эфире через призму технологий и хипстерства. Мне показалось, что вы при этом неявно высказываетесь в пользу того, что гнаться за новым не надо (мол, клиенты голосуют за XML, вот и надо залипнуть на нем), а я утверждаю, что гнаться надо, но по-другому. Если показалось неправильно, значит, показалось неправильно.
BDA>>Была у них такая система — Windows Mobile. S>Вот тут 100% менеджмент-фейл, с технической стороны винфон на сегодня — одна из самых изящных платформ. С продвижением ёк, ну так вообще удивительно, что оно вообще продаётся, с таким-то творческим подходом.
Вы так говорите, как будто возражаете мне. Между тем, я об этом и пишу: да, это фейл менеджмента, и в чем он, собственно, состоит? А в том, что нельзя резко вводить технические улучшения (которые делают всю изящность) туда, где клиенты всем довольны. Рано или поздно они сами дозреют, но без мыслей скипнуть к черту.
BDA>>Понимаете, к чему я веду? Реальные клиенты их давно линяют по другим платформам. S>А вот тут — фига с два. Просто большинство клиентов плавно переползают с самосбора на решения "допилить напильником". Ну, т.е. в нишу конструкторов сайтов, пхп и 1с
Опять же, на что вы возражаете? Линяют же?
BDA>>Эволюция идет с неизбежностью ледника. Переходи они на json или не переходи, рано или поздно кранты ихнему ASP. S>И снова нет — куда ж они денутся? Отток возможен только для прослойки "что в дизайн-студии предложили, то и взяли". Это товарищи постоянные, как флюгер, каждые два года фаворит меняется. Легко пришло — легко ушло короче.
А вот увидите. Лет через 10 вспомните мои слова. Прямо сейчас есть альтернативы в виде Symfony и Java для новых проектов, за ними стоят люди, которые не как флюгер, каждые несколько лет не переделывают все заново. И не клоуны, которые айфон хоронят (ведь, позорище же). И не идиоты, которые бесят лояльную клиентуру (в прямом эфире). Кто сейчас в здравом уме будет с ними связываться? Все они висят только на одной сопле — наследии Гейтса. Вот вы тут аспшничаете почему? Не потому ли, что пятнадцать лет назад встали на эти лыжи? Ну а я их снял. По асфальту не едут
А будущее, все-таки, за Node.JS и json.
BDA>>И они это понимают. Студия 2015, ИМХО, интересна только потому, что Node.JS поддерживает из коробки, вместе с редактором клиентских скриптов. S>Ну блин, снова вы на следствия смотрите, а не на первопричины. Второй год на конференциях прямым текстом рассказывают что и почему. Они не только ноду поддерживают, они практически всё к себе под крыло сгребают. Вон недавно про .net-стек расписывал
Здравствуйте, 0BD11A0D, Вы писали:
S>>Ну по-хорошему да. В смысле, не пользователя менять, а подход. Или просить заказчика предоставить xsd-схему (это заодно решает 1000 других вопросов), или не притворяться, что у вас валидный xml. BDA>Ну, дадут схему, а там одни аттрибуты. Или все в ноды свалено. И что? Если техническая проблема имеет место, схема ее не закроет.
Ну и ок. Раз заказчик формат выбрал — так и выгружаем. Другой заказчик попросит смесь из атрибутов/контента, третий ещё что-то придумает, в любом из вариантов у нас будет валидный xml. С json всё печальней, там даже схем толком нет.
BDA>Просить заказчика об xsd-схеме, когда он сам в ней не заинтересован, это, зачастую, итальянская забастовка. На свободном рынке обструкционизм несовместим с заработками. Может, еще функциональную спецификацию просить?
Ну давай от темы не уклоняться, м? Проблема у вас по факту была не в "нужны только атрибуты / контент", а в том, что вы пытались обмениваться xml без схемы. В общем, вы узнали, зачем нужны xsd сложным способом.
BDA>1. Зато такой XML, в свою очередь, плохо ложится на SQL;
Все нормальные базы наотлично умеют в xml. В том числе и разбирать xml на отдельные записи.
BDA>2. Зато правильно писать такой XML труднее;
Все нормальные редакторы умеют проверку xml-я на базе xsd-шек. Снова "просто используй нормальные инструменты".
BDA>3. Зато (были?) проблемы с парсингом.
Ну как бы обсуждали уже. Проблема оказалась не с парсингом. Проблема в том, что вы выдавали xml, не подходящий под формат заказчика. Снова нутыпонял
BDA>Любая метафора имеет свои ограничения. Для меня важно, что Майкрософт в погоне за новыми рынками забивает на текущую клиентуру.
А, ну тогда мы об одном и том же говорим. И я не сказал бы, что это что-то новое (перевод). Смотрим на дату поста
BDA>А будущее, все-таки, за Node.JS и json.
Воот очень с большим скепсисом. Не, в первые два-три раза можно повестись. А вот когда подобных "наше всё" перевидал с десяток и все как одна в итоге сдулись в свою родную нишу, на очередные решения-для-всего всерьёз смотреть не получается.
S>>Ну блин, снова вы на следствия смотрите, а не на первопричины. BDA>Евангелизм меня мало интересует и их самопиар тоже.
Чой то вас снова занесло. Вам расписывают как оно на самом деле обстоит, а вы про евангелизм начинаете. Фу-фу-фу так делать.
S>Все нормальные редакторы умеют проверку xml-я на базе xsd-шек. Снова "просто используй нормальные инструменты".
Хм, хорошее предложение, если бы не одно «но»: иногда нет доступа к «нормальным инструментам». Из практики, приезжаешь на объект, надо быстренько поправить конфиг, небольшой такой, 20000 строчек всего, а на машине кроме нотпада ничего нет, голый MS Server.
PS И не надо мне тут рассказывать, что «нормальные инструменты» надо с собой возить, нету возможности запустить «нормальные инструменты».
Здравствуйте, Dym On, Вы писали:
DO>Хм, хорошее предложение, если бы не одно «но»: иногда нет доступа к «нормальным инструментам». Из практики, приезжаешь на объект, надо быстренько поправить конфиг, небольшой такой, 20000 строчек всего, а на машине кроме нотпада ничего нет, голый MS Server.
Внезапно инструменты надо не только ставить, но и использовать
В "голом" сервере есть ie, который наотлично показывает xml-ки, уж найти-то нужное место с помощью него несложно.
Если стоит ms sql, то SSMS умеет XML, начиная с 2005го.
DO>PS И не надо мне тут рассказывать, что «нормальные инструменты» надо с собой возить, нету возможности запустить «нормальные инструменты».
В смысле? Ни vs online, ни файл на свой ноут перекинуть, ни флешку воткнуть?
Ну молодцы конечно. Но как это относится к 99% более реалистичных сценариев?
UPD А, ну и с интересом заслушал бы, как нам тут поможет json. Он как правило раза в полтора длиннее по строчкам, если что. Про "сбалансировать скобки после редактирования" не будем. Незачем троллить
S>Внезапно инструменты надо не только ставить, но и использовать S>В "голом" сервере есть ie, который наотлично показывает xml-ки, уж найти-то нужное место с помощью него несложно.
IE это не нормальный инструмент. Внезапно, его приходится использовать, но редактировать все равно в нотпаде . Ну нашел ты нужную запись в 7654 строке, надо значение поправить и как это сделать с помощью ie? Особенно зачетно, бывает если кто-то до тебя лишний пробел между атрибутами поставил.
S>Если стоит ms sql
не стоит
S>В смысле? Ни vs online, ни файл на свой ноут перекинуть, ни флешку воткнуть?
Именно так.
S>Ну молодцы конечно. Но как это относится к 99% более реалистичных сценариев?
В моем случае это 100% сценариев.
S>UPD А, ну и с интересом заслушал бы, как нам тут поможет json. Он как правило раза в полтора длиннее по строчкам, если что. Про "сбалансировать скобки после редактирования" не будем. Незачем троллить
Совершенно верно. Поэтому, когда я еще занимался непосредственно программированием, я с какого-то момента конфиги делал в стиле unix, т.е. ключ=значение, все легко правиться в нотпаде.
Здравствуйте, Mystic, Вы писали:
vsb>>Это называется мода.
M>Я бы не сказал, что это мода. Это типичная ситуация, когда некоторые программисты, как я понимаю, вроде тебя, потратили N человеко-месяцев на изучение многих возможностей XML, и научились его готовить. А другая часть, вроде меня, пожалели на это время. Ну и когда распространился JSON, который можно выучить за пару часов, и который покрывает 99% их потребностей, начали его использовать.
Какие пару часов? Синтаксис XML очевиден за пару минут, что там изучать пару часов, если не влезать в подводные камни. Как и JSON, конечно. А на то, что я потратил N человеко-месяцев, у JSON-а нормальных инструментов в принципе нет. Поэтому если они не нужны — разницы между XML и JSON нет почти никакой, оба варианта просты и интуитивно понятны. Разве что XML имеет стандартное API и библиотеки под практически любой ЯП, так что достаточно выучить его один раз и можно использовать в любом ЯП, в то время как JSON под каждый язык имеет свои библиотеки со своим интерфейсом.
Единственное значимое отличие XML от JSON это то, что в JSON отдельно выделена структура "array", "dictionary", а в XML более простая структура и её отображение на "array", "dictionary" приходится делать несколько сложней.
Здравствуйте, vsb, Вы писали:
vsb>Какие пару часов? Синтаксис XML очевиден за пару минут, что там изучать пару часов, если не влезать в подводные камни.
Кому очевиден ? Люди без продакшн опыта спотыкаются в XML годами, а JSON воспринимают даже не задумываясь.
>А на то, что я потратил N человеко-месяцев, у JSON-а нормальных инструментов в принципе нет. Поэтому если они не нужны — разницы между XML и JSON нет почти никакой, оба варианта просты и интуитивно понятны.
Интуитивно-понятно это мягко говоря преувеличение. JSON понятен любому, кто хотя бы кое что пробовал на JS, а это студенты начиная с колледжей. XML по факту приходится учить в явной форме
1 синтаксис — что бы не путали слеши, правильно ставили угловые скобки и тд и тд.
2 схемы всякие
3 инструментам
4 АПИ
vsb>Единственное значимое отличие XML от JSON это то, что в JSON отдельно выделена структура "array", "dictionary", а в XML более простая структура и её отображение на "array", "dictionary" приходится делать несколько сложней.
Вот-вот. В XML тип определяется схемой. В JSON — синтаксисом.
Здравствуйте, Young, Вы писали:
Y>При том что именно читать YAML удобней чем все другие форматы.
1. JSON — подмножество YAML.
2. Мне лично YAML'овские конструкции читать тяжелее, чем XML и JSON. Местами они неожиданные (типа влияния отступов или когда можно строку не квотить).
Здравствуйте, netch80, Вы писали:
I>>Кому очевиден ? Люди без продакшн опыта спотыкаются в XML годами, а JSON воспринимают даже не задумываясь. N>Если их воспринимать на одинаковом уровне — без схемы — разницы нет.
Оно и видно — за новичками в xml надо вагоны ошибок исправлять,а c JSON как то сами справляются.
Здравствуйте, Pzz, Вы писали:
Pzz>Я не понимаю, почему нельзя в JSON добавить комментарии в синтаксисе C/C++/JavaScript.
Потому что всех прочих проблем json оно никак не решит. Ну не годится этот формат ни для чего, кроме как для перекидывания данных веб-страничкам. Да и там не без фейлов типа работы с датами.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, sambl4, Вы писали:
S>>Стандартный ответ json-фагов — можно добавить свойство "Comment"
Pzz>Я не понимаю, почему нельзя в JSON добавить комментарии в синтаксисе C/C++/JavaScript.
Здравствуйте, netch80, Вы писали:
Pzz>>Я не понимаю, почему нельзя в JSON добавить комментарии в синтаксисе C/C++/JavaScript.
N>Обратная совместимость?
Да, если этот JSON предполагается давать на вход ранее написанным программам. Но если речь идет о конфиге новой программы?...
Здравствуйте, Ikemefula, Вы писали:
vsb>>Какие пару часов? Синтаксис XML очевиден за пару минут, что там изучать пару часов, если не влезать в подводные камни.
I>Кому очевиден ? Люди без продакшн опыта спотыкаются в XML годами, а JSON воспринимают даже не задумываясь.
>>А на то, что я потратил N человеко-месяцев, у JSON-а нормальных инструментов в принципе нет. Поэтому если они не нужны — разницы между XML и JSON нет почти никакой, оба варианта просты и интуитивно понятны.
I>Интуитивно-понятно это мягко говоря преувеличение. JSON понятен любому, кто хотя бы кое что пробовал на JS, а это студенты начиная с колледжей.
Ваши студенты знают JS, но не видели HTML?
I>XML по факту приходится учить в явной форме I>1 синтаксис — что бы не путали слеши, правильно ставили угловые скобки и тд и тд.
И сколько этому надо "учить"? Собственно это и есть аналог JSON.
I>2 схемы всякие I>3 инструментам I>4 АПИ
А этого у JSON нет, поэтому и учить нечего.
vsb>>Единственное значимое отличие XML от JSON это то, что в JSON отдельно выделена структура "array", "dictionary", а в XML более простая структура и её отображение на "array", "dictionary" приходится делать несколько сложней.
I>Вот-вот. В XML тип определяется схемой. В JSON — синтаксисом.
В JSON тип вообще никак не определяется, нет стандартных инструментов, есть разного рода попытки.
Здравствуйте, vsb, Вы писали:
>>>А на то, что я потратил N человеко-месяцев, у JSON-а нормальных инструментов в принципе нет. Поэтому если они не нужны — разницы между XML и JSON нет почти никакой, оба варианта просты и интуитивно понятны.
I>>Интуитивно-понятно это мягко говоря преувеличение. JSON понятен любому, кто хотя бы кое что пробовал на JS, а это студенты начиная с колледжей.
vsb>Ваши студенты знают JS, но не видели HTML?
Студенты учат или джаву, или С++ и такой синтаксис поняет. JS заходит сам собой. А вот HTML или не видели, или он дает превратное представление об XML.
I>>XML по факту приходится учить в явной форме I>>1 синтаксис — что бы не путали слеши, правильно ставили угловые скобки и тд и тд.
vsb>И сколько этому надо "учить"?
Долго, пока не перестанут тривиальные ошибки делать
I>>2 схемы всякие I>>3 инструментам I>>4 АПИ
vsb>А этого у JSON нет, поэтому и учить нечего.
Схемы, инструменты, апи использовались раньше для тех вещей, которые сейчас делаются совсем иначе.
Раньше было модно использовать XSLT преобразование и подобные чудеса. Сейчас такая хрень никому не нужна. Вместо этого ты отдаёшь данные в чистом виде и дальше клиент, как правило веб, сам всё сделает.
I>>Вот-вот. В XML тип определяется схемой. В JSON — синтаксисом. vsb>В JSON тип вообще никак не определяется, нет стандартных инструментов, есть разного рода попытки.
Здравствуйте, Cyberax, Вы писали:
vsb>>Какие пару часов? Синтаксис XML очевиден за пару минут C>Да? Включая entities, namespace'ы, схемы, кодировки и т.д.?
entities это просто escape-ing. Не сложнее "\uabcd". Вроде есть какая-то муть с DTD, но оно никому не надо. Что там с кодировками, я не знаю, UTF-8 и всё. Остального в JSON нет и к синтаксису это не относится, поэтому из сравнения вычёркиваем, сравниваем сравнимое. Аналог JSON это конструкция вида
<?xml version="1.0"encoding="UTF-8"> <!-- это магическая строчка -->
<tag> <!-- это тег -->
<another-tag> <!-- это вложенный тег -->
<foo bar="qwerty"> <!-- это атрибут -->
<foobar/> <!-- это самозакрывающийся тег -->
</foo> <!-- это закрывающий тег -->
</another-tag>
</tag>
Всё. Этого хватает, чтобы работать с XML на уровне JSON. Всё остальное это уже надстройки, и если мы сравниваем их, то надо включать аналогичные стандарты для JSON (которых нет).
Здравствуйте, Ikemefula, Вы писали:
vsb>>А этого у JSON нет, поэтому и учить нечего.
I>Схемы, инструменты, апи использовались раньше для тех вещей, которые сейчас делаются совсем иначе. I>Раньше было модно использовать XSLT преобразование и подобные чудеса. Сейчас такая хрень никому не нужна. Вместо этого ты отдаёшь данные в чистом виде и дальше клиент, как правило веб, сам всё сделает.
XSLT и подобные чудеса никуда не девались. В JSON их не завезли, да, это печаль. Поэтому видимо и не нужна Что предлагает JSON для конвертации из одного формата в другой? Про "отдаёшь данные в чистом виде" не надо, в реальном мире потребность в конвертации возникает на каждом шагу. Всё, что может предложить JSON это писать логику на ЯП общего назначения, которая будет заведомо проигрывать специализированному языку вроде XSLT или CDuce. И хорошо, если этот ЯП общего назначения достаточно мощный. А чаще всего пишут на убогом JS рассыпную лапшу из десятков if-ов.
I>>>Вот-вот. В XML тип определяется схемой. В JSON — синтаксисом. vsb>>В JSON тип вообще никак не определяется, нет стандартных инструментов, есть разного рода попытки. I>Покажи, для чего тебе нужны инструменты
Для чего нужна XML Schema? Во-первых для документирования формата. Причём это документирование может использоваться умными редакторами для очень удобного редактирования XML, если вдруг это нужно. Во-вторых для первичной валидации данных на соответствие формату. В-третьих для автоматической генерации кода сериализатора, который будет преобразовывать данные из XML в объекты целевого ЯП. Есть ещё много интересных применений, например WSDL, позволяющий в два клика связывать программы на совершенно разных языках, платформах и тд, без каких-либо затрат на разработку парсера, сериализатора, валидатора и других скучных, далёких от бизнес-логики вещей.
Здравствуйте, vsb, Вы писали:
vsb>>>Какие пару часов? Синтаксис XML очевиден за пару минут C>>Да? Включая entities, namespace'ы, схемы, кодировки и т.д.? vsb>entities это просто escape-ing. Не сложнее "\uabcd". Вроде есть какая-то муть с DTD, но оно никому не надо.
Авотщаз. Можно определять custom entities, которые будут содержать куски XML:
<?xml version="1.0"?>
<!DOCTYPE some [<!ENTITY test "This is a test<script>Mwhaha</script>">]>
<some>
&test;
&test;
</some>
Здравствуйте, vsb, Вы писали:
vsb> Всё, что может предложить JSON это писать логику на ЯП общего назначения, которая будет заведомо проигрывать специализированному языку вроде XSLT или CDuce. И хорошо, если этот ЯП общего назначения достаточно мощный. А чаще всего пишут на убогом JS рассыпную лапшу из десятков if-ов.
Можно вопрос? А вы сами писали сколь-либо сложные шаблоны на XSL?
Попробуйте. Если применять XSL не для замены одного тэга на другой, то что-либо внятное на нём превращается в жутикового тормозного монстра. После которого обычный ЯП будет казаться манной небесной, даже с учётом XML DOM API, спроектированного полными дебилами.
Ну и таки аналоги XSL для JSON есть, причём более мощные: http://jsoniq.org/ Просто они нужны далеко не всем, вот и непопулярны.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vsb, Вы писали:
vsb>>>>Какие пару часов? Синтаксис XML очевиден за пару минут C>>>Да? Включая entities, namespace'ы, схемы, кодировки и т.д.? vsb>>entities это просто escape-ing. Не сложнее "\uabcd". Вроде есть какая-то муть с DTD, но оно никому не надо. C>Авотщаз. Можно определять custom entities, которые будут содержать куски XML:
Можно, но, как я и писал, никому оно не надо. DTD почти нигде не используется (т.к. Schema это более удобная и мощная альтернатива) и в парсерах зачастую вообще отключается. Опять же рассматриваются возможности, аналогов которым у JSON нет.
Здравствуйте, Cyberax, Вы писали:
vsb>> Всё, что может предложить JSON это писать логику на ЯП общего назначения, которая будет заведомо проигрывать специализированному языку вроде XSLT или CDuce. И хорошо, если этот ЯП общего назначения достаточно мощный. А чаще всего пишут на убогом JS рассыпную лапшу из десятков if-ов. C>Можно вопрос? А вы сами писали сколь-либо сложные шаблоны на XSL?
Относительно сложные писал и поддерживал, в пару сотен строк (несколько десятков строк логики).
C>Попробуйте. Если применять XSL не для замены одного тэга на другой, то что-либо внятное на нём превращается в жутикового тормозного монстра. После которого обычный ЯП будет казаться манной небесной, даже с учётом XML DOM API, спроектированного полными дебилами.
"Что-нибудь внятное" на SQL тоже превращается в жуткого тормозного монстра и зачастую приходится этого монстра переписывать на традиционном ЯП, разбивая на несколько простых запросов. Это же не повод отказываться от SQL. Так и тут. Есть определённые границы применимости и в их рамках XSLT очень удобен.
Здравствуйте, Cyberax, Вы писали:
C>Можно вопрос? А вы сами писали сколь-либо сложные шаблоны на XSL?
Я писал.
C>Попробуйте. Если применять XSL не для замены одного тэга на другой, то что-либо внятное на нём превращается в жутикового тормозного монстра.
Не превращается.
C> После которого обычный ЯП будет казаться манной небесной
На этих задачах — точно не будет.
C>Ну и таки аналоги XSL для JSON есть, причём более мощные: http://jsoniq.org/
Здравствуйте, vsb, Вы писали:
C>>Авотщаз. Можно определять custom entities, которые будут содержать куски XML: vsb>Можно, но, как я и писал, никому оно не надо. DTD почти нигде не используется (т.к. Schema это более удобная и мощная альтернатива) и в парсерах зачастую вообще отключается.
Речь шла о том, что "да весь XML за 10 минут можно изучить!". Нет, нельзя. И про такие особенности надо знать, иначе можно получить уязвимость в своём приложении.
vsb>Опять же рассматриваются возможности, аналогов которым у JSON нет.
Схемы для JSON тоже есть.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>http://jsoniq.org/docs/JSONiq-usecases/html/ch01.html#json2json НС>XQuery тоже такое умеет. Однако популярности, в отличие от XSLT, так и не получил.
XSLT её тоже не особо получил. Просто долгое время он был единственным "официальным" способом делать преобразования XML. XSLT появился в 97-м году, а XQuery — в 2007-м, когда на XML уже начали забивать.
Здравствуйте, Cyberax, Вы писали:
НС>>XQuery тоже такое умеет. Однако популярности, в отличие от XSLT, так и не получил. C>XSLT её тоже не особо получил.
А это откровенная неправда.
C> Просто долгое время он был единственным "официальным" способом делать преобразования XML.
Преобразовывать любым понравившимся языком программирования его никто не запрещал.
C> XSLT появился в 97-м году, а XQuery — в 2007-м, когда на XML уже начали забивать.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>XQuery тоже такое умеет. Однако популярности, в отличие от XSLT, так и не получил. C>>XSLT её тоже не особо получил. НС>А это откровенная неправда.
Так не получил. Где вот он сейчас используется?
C>> Просто долгое время он был единственным "официальным" способом делать преобразования XML. НС>Преобразовывать любым понравившимся языком программирования его никто не запрещал.
Долгое время официальным способом сохранить XML было использовать идентичное преобразование. XSL форсировался везде, куда только можно. XSL-FO все помнят, например?
C>> XSLT появился в 97-м году, а XQuery — в 2007-м, когда на XML уже начали забивать. НС>Оно и видно как все на XML забили.
Ну кто-то продолжает кушать кактус, понимаю.
Здравствуйте, Cyberax, Вы писали:
C>>>XSLT её тоже не особо получил. НС>>А это откровенная неправда. C>Так не получил. Где вот он сейчас используется?
В миллионе сайтов и корморативных систем.
C>>> Просто долгое время он был единственным "официальным" способом делать преобразования XML. НС>>Преобразовывать любым понравившимся языком программирования его никто не запрещал. C>Долгое время официальным способом сохранить XML было использовать идентичное преобразование.
Чего?
C> XSL форсировался везде, куда только можно. XSL-FO все помнят, например?
НУ так вот XSL-FO, не смотря на формирование, так популярности и не получил. А вот XSLT — получил.
НС>>Оно и видно как все на XML забили. C>Ну кто-то продолжает кушать кактус, понимаю.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>А это откровенная неправда. C>>Так не получил. Где вот он сейчас используется? НС>В миллионе сайтов и корморативных систем.
Что-то я сомневаюсь в миллионах. В моём локальном корпоративчике, например, я не встречал XSL. Хотя у нас есть экзотика типа Rust и Scala. Так что какой-либо существенной роли XSL не играет.
Можно посмотреть на SO: http://stackoverflow.com/search?q=XSL — всего 38 тысяч вопросов.
C>>Долгое время официальным способом сохранить XML было использовать идентичное преобразование. НС>Чего?
Того. В DOM API от W3C не определено как сохранять документы. Поэтому для той же Java долгое время официальный способ выглядел так:
Transformer transformer = TransformerFactory.newInstance().newTransformer();
Result output = new StreamResult(new File("output.xml"));
Source input = new DOMSource(myDocument);
transformer.transform(input, output);
Не, потом это всё поправили, когда XML стал на практике нужен. В .NET сразу сделали правильно, например.
НС>>>Оно и видно как все на XML забили. C>>Ну кто-то продолжает кушать кактус, понимаю. НС>Отличный аргумент.
Ну таки ведь да.
Здравствуйте, Cyberax, Вы писали:
C> В моём локальном корпоративчике, например, я не встречал XSL.
Да ты много чего не встречал. И регулярно делаешь одну и ту же ошибку — считаешь что твои локальные задачи это все. что в природе существует. Я еще помню твои давние разглагольствования про задачу составления расписания, и глобальные выводы об ORM и РСУБД, которые ты на ее основании делал.
C> Хотя у нас есть экзотика типа Rust и Scala.
Зная тебя уверен — подтасовку ты сделал намеренно. http://stackoverflow.com/search?q=XSLT
C>>>Долгое время официальным способом сохранить XML было использовать идентичное преобразование. НС>>Чего? C>Того. В DOM API от W3C не определено как сохранять документы. Поэтому для той же Java
Это личные проблемы джавы.
C>Не, потом это всё поправили, когда XML стал на практике нужен. В .NET сразу сделали правильно, например.
И не только в .NET.
НС>>Отличный аргумент. C>Ну таки ведь да.
.NET Core will be expanding its API support to include the Mono API surface area, to support Unity / UWP apps
.NET Core will be back in web browser (for some reason) again once WebAssembly finishes
Mscorlib may, or may not be coming back. Or maybe we’ll be using NuGet. #YOLO
AppDomains and other excluded features may be coming back, but different
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
S>>TOML тож немногим лучше — один таб == один пробел, насколько помню. Может поменялось, давно смотрел. Н>TOML:Indentation (tabs and/or spaces) is allowed but not required Н>Т.е. используется только для визуальной "красоты":
Н>
Н>[servers]
Н> # Indentation (tabs and/or spaces) is allowed but not required
Н> [servers.alpha]
Н> ip = "10.0.0.1"
Н> dc = "eqdc10"
Н> [servers.beta]
Н> ip = "10.0.0.2"
Н> dc = "eqdc10"
Н>
Так этож ini файл!
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, gandjustas, Вы писали:
_>>Думаю что в подавляющем большинстве обсуждаемых тут случаев (посмотри о чём была речь выше), возможностей парсера на базе спирита более чем хватит. G>Более чем хватит для чего? Чтобы хоть как-то заработал конечно хватит. Если для обработки сотен тысяч сериализаций-десериализаций в секунду, то вряд ли.
Спирит тоже по-разному можно использовать. Конкретно по ссылке автор не заморачивался, там строка представлена строкой С++, т.е. каждый токен из исходного потока будет копироваться и для него будет аллоцироваться (с большой вероятностью) память. Можно было строку заменить парой итераторов (или указателей), там разница до 20-50 раз в быстродействии обычно получается.
И да. Если в компиляторе стоит опция юзать SSE, то бустовский спирит прекрасно компилится с помощью SSE. Весь код шаблонный и доступен для оптимизации.
Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?
Есил я всё правильно понимаю то причина простая. Новая студия пишется на жаба скрипте.
Tom>>Есил я всё правильно понимаю то причина простая. Новая студия пишется на жаба скрипте. НС>Ты все неправильно понимаешь.
да ну VS Code как и студия в облаке — это жаба скрипт.
Здравствуйте, Sheridan, Вы писали:
S>Ну имхо json это самый удобный вариант для конфигов. Категорически прост, древовиден, структуризован, типизирован и не так наворочен, как xml. S>По личному опыту: xml трудно читать, количество скобок превышает все мыслимые пределы, закрывающие теги только мешают
LUA надо использовать. Структуры данных такие же простые, комментарии есть, можно еще по ходу загрузки конфига данные им в себя генерить.