OberonCore

По-моему, можно сейчас найти много примеров, где данные, предназначенные исключительно для машинной обработки, сохраняются в гораздо более неэффективной для этого текстовой форме.
- стандарт xml
- дампы базы mysql
- дампы хранилища subversion
...

При том, что оптимизировать, у ИТ-специалистов вроде как принято.

Учитывая текущую (по основной массе, это моё, ничем не подкреплённое, предположение) "безассертовую" культуру и небезопасные средства программирования (Си/Си++/Дельфи/...), можно говорить о том, что многие баги приводят к порче данных.

Данные, сохранённые в текстовом виде, всегда можно подправить вручную до валидного состояния --- в любом текстовом редакторе. С бинарными этого так просто не сделать.

Вывод:
небезопасные средства и стиль пр-я --> большое число багов, портящих данные --> боязнь таких багов в "данно-ориентированных" задачах --> выбор текстового представления для возможности ручного анализа и коррекции в экстренных случаях

Ну, тут несколько пошире факторы.
В целом подсознательная тяга к наглядной диагностируемости (не только в случае повреждения, а при сетевых взаимодействиях - виднее, типа, что происходит). Не могут договориться о бинарных форматах в случае разных платформ. Ну и т.п.
Нашли некий "общий знаменатель", с которым готовы смириться все.

Плюс в разных скриптомакроязыках традиционно туго с работой с байтами. А с текстами проще.

То, что факторов не один, понятно. Интересно --- является ли среди них озвученный одним из важных?

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

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

Хотя данные бывают разные. Например, коротко живущие объекты сообщений - это одно, а вечно хранимые документы - другое.

У меня крутились схожие мысли уже относительно давно, только письменно я их нигде не излагал.

Интересно, кто решил, что данные в XML легко читать? Почему интернет работает по спецификации гипертекстового языка разметки?

Данные в текстовом виде:

1. избыточны, что ведёт к повышенному расходу ресурсов (по обработке данных, по их передаче, в хранении в накопителях данных),
2. подвержены искажению информации, так не применяются различные техники сверки достоверности данных (CRC и прочие), а человек не может безошибочно проверить её,
3. влекут более трудоёмкие операции в их изменении, нежели бинарные.

Дык, разве кто-нибудь, кроме советских военных (да и то не всегда) ставил задачу экономии ресурсов?!

Наоборот, вся промышленность построена сегодня так, чтобы была потребность тратить этих ресурсов как можно больше (это ж прибыль!).

Данные, может, и не легко, а вот XML-документ читается вполне себе неплохо, потому что удобочитаемость человеком была одной из целей создания XML:



http://www.w3.org/TR/xml/

Мне думается, расширяемость относительно бинарных форматов у текстовых(XML например) крайне высока... хотя, конечно, смотря что хранитьили передавать(как в джаббере).

Недостатки бинарных custom-форматов (т.е. склёпанных под разовую нужду) известны.

Но можно ведь говорить о бинарных, а не о custom-форматах.

Хотя бы о том, что тот же XML, как древовидная модель, (а имеется спец. стандарт древовидной модели, XQuery определён над ней, а не над XML) мог бы иметь стандартное бинарное представление.

Например, словарь тегов в начале, а дальше ссылки по номеру на этот словарь - и т.п. Сколько экономии.

А ещё можно было бы накласть на совместимость с SGML и упростить в целом.

Ещё раз:

Это делается для последующего расширения формата. Придает гибкость. Стандартно же -- tlv (type, length, value). На type легко вешается обработчик. Получаем эдакий SAX для бинарного формата. Очень удобно. Расширяемо. Также следует учесть, что если протокол вдруг поменялся, и вы нагенерили новых сериализаторов/десериализаторов, это не значит что в системе сразу все компоненты перешли на новый протокол.

Кроме того, частенько туда пишут не тип, а например как в google protobuf'e, номер поля (ну, можно считать что каждое поле имеет свой уникальный тип). Что делается опять таки для расширизмов. Например благодаря этому механизму реализованы опциональные поля (да, если опциональное поле в данном сообщении отсутствует (не нужно) то оно и небудет передано/сериализовано). Опять же -- весьма удобно.

Кстати, а при чем тут именно сишники?

Да, на счет текстовых форматов/протоколов. Когда у производительность не критична (а она очень часто не критична), то при прочих равных следует выбирать тот формат, который можно будет обработать максимально широким спектром утилит (проанализировать, посмотреть, отредактировать). Таковой формат -- всегда текстовый формат, причем ASCII. Написание своих тулзей для просмотра своего же бинарного формата черевато ошибками. Смотришь через эту тулзень на данные, видишь хрень, и непонятно из за чего хрень -- толи это данные не правильные, толи это в тулзени бага. В общем, нужны очень веские основания для отказа от моря стандартный утилит (grep, awk, cat and so on) для обработки данных в пользу своего велосипеда.

Полагаю, что формат XML является переходным этапом пока не станет достаточно зрелым. Когда он применялся в начале, было недостаточно понимания как удобно хранить информацию. Человеку проще видеть перед глазами набор осмысленных символов, чем на бинарных данных.
А если данные представлять в удобном для понимания виде, а хранить - в удобном для ЭВМ? Программа сможет безошибочно и эффективно хранить данные.

Ну, уже 14 лет как переходный )

Дык есть же бинарное представление xml : http://ru.wikipedia.org/wiki/WBXML
Всё давным-давно изобретено.

Он не переходный. Он базовый. В том плане что наработаны богатые методики, созданы библиотеки, утилиты и проч. для удобной обработки, создания, и анализа его. На базе xml уже лепится то что нужно в данной задаче. Если не укладываемся по объемам/производительности, втыкаем WBXML (при этом НИЧЕГО менять не придется). Если и тут просаживаемся по производительности, то есть повод задуматься куда двигаться дальше. Толи не оптимально построен наш формат/протокол поверх xml, толи да, нужно перехидить на что-то менее универсальное нежели xml (в любом представлении). Но в любом случае к тому моменту уже станет четко ясно каков наш протокол/формат и как реализовывать велосипед.

Итерационная модель разработки же.

Нужно применять контрольные суммы и другие техники проверок. Тогда и будет понятно где искать ошибку. Пример: заголовок пакета IP.

Не успеваю отвечать с мобильника.

Не будет понятно где ошибка. Будет понятно что просто есть ошибка.
Кроме того, CRC может быть правильной, а вот внутри может быть мусор. В том плане, что просто скрыша съехала у отправителя и значения вылезли за допустимые диапазоны. Вы видели когда-нибудь udp пакет приехавший с нулевого порта? А я вот видел.

Ещё раз -- нужны очень веские основания чтобы отказываться от стандартных средств обработки данных. Покуда таких оснований нет, текстовое представление -- наше всё.

Да, а ещё бывает, что с пакетом всё хорошо. просто побилась, или не правильно была подсчитана контрольная сумма. Но нам таки нужно вытащить информацию которая сидит в пакете. Или два пакета слиплись в один. В общем существует множество багов при которых текстовое представление предпочтительней. Разработка быстрее и приятней.

Например на текстовые данные можно легко натравить программу на Рефале. На бинарные данные уже так просто не натравишь. Нужен будет конвертер, который может добавить своих ошибок. К чему лишние прослойки?