Вы упорно продолжаете. Не нужно мне навязывать ваше понимание того, что я сказал,
так же как и не нужно мне навязывать какие символы я могу использовать, а какие нет.
>В Tree нет ключей
Вы прекрасно поняли что я имел ввиду имена узлов.
Я отлично понимаю что представляет из себя то, что вы показываете и ни через какую призму не смотрю.
Почему вы, вместо того, чтобы обратить внимание на то, что вам говорят, думаете, что вас не понимают и пытаетесь объяснить мне древовидную структуру мне не ясно.
1. Ограничение на ключи
С этим явно нужно что-то делать. Думаю, объяснять почему смысла нет.
2. Разделитель ключа и значения " ="
Вам, почему-то, кажется, что это совершенно неважная вещь. Но, я думаю, вы уже заметили, что многим это совершенно не нравится. Не потому, что это не привычно, а потому, что на это больно смотреть. Вы, наверняка, знаете это чувство, когда смотришь на код, который делает все как нужно, но выглядит «не так».
Кроме того, вы обосновываете это решение тем, что «это целый лишний пробел». Но, во-первых, в современных реалиях удобство программиста ставится выше эффективности кода (не могу сказать хорошо это или плохо, но это так). А во-вторых, вы все равно не сделаете здесь более эффективно, чем чисто бинарные форматы.
Так есть ли смысл ставить под удар «юзабельность», ради выигрыша нескольких байт?
3. Необходимость экранирования переноса строки в сырых данных.
Расходы на экранирование будут возрастать пропорционально объему этих данных. То же самое при извлечении этих данных. Здесь, кстати, есть и другая проблема: придется перевыделять память каждый раз, как мы дойдем до предела буффера, потому, что не известно сколько нужно еще считать
Решить это можно, например, введя спецификатор размера значения.
>xml тоже можно использовать без схемы и деклараций
Не спорю, можно. Но несколько сложнее, взять хотя бы проблему выбора между атрибутом и дочерним элементом.
>Я уже устал повторять, что Tree — это формат, а не язык
Извините, что утомил вас. Не волнуйтесь, я помню, и это очевидно из его сравнение с JSON, XML, YAML.
Перефразирую: если формат не предоставляет достаточно конструкций сам по себе, то их придется где-то описывать. Пример с массивами: да, в JSON они нумеруются от 0 и только так. Но в Tree такого нет вообще. Нигде не написано, являются ли дочерние узлы упорядоченными или нет и какие им даются индексы. А это значит, что придется вводить новую спецификацию (схему), для того, чтобы это описать.
Если вы подразумеваете, что в чистом виде он никогда не будет использоваться, то презентуйте его как мета-формат.
>только на изучение каждого инструмента нужно время
Даже если описать все эти языки в рамках одного формата, это не делает изучение более простым
>таскать их все с собой не очень удобно
Как это отличается от все-в-одном?
>Плюс ещё и стыкуются они друг с другом плохо
Весьма спорное утверждение. Все зависит от конкретного случая.
Напомню, что сама идея, мне нравится. Мне не нравится её текущая реализация и тот факт, что эту реализацию пытаются выдать за «убийцу» вышеперечисленных форматов.
>А при чём тут схема?
При том, что ей вы описываете что есть что. Если в языке нет необходимого минимума, то приходится описывать вообще все.
>В чём проблема запилить схему?
Только в том, что это нужно сделать. И чем раньше это «нужно» появится, тем хуже.
>Вы попробуйте сначала, а потом уже говорите о неудобности.
Пробовал уже. Как только вы для этого предложили нечто похожее на формы Бэкуса-Наура.
В связи с чем, кстати, появился вопрос: как вам идея использовать вместо вашего решения bison? Он несравнимо более гибок, да и реализация уже есть. Получаем сразу и описание формата и парсеры под все популярные языки.
>Всякие BSON и прочие бинарники имеют сильно ограниченное применение
Тем не менее в бинарной области они работать будут лучше чем та спецификация Tree, что вы показываете. А в «небинарной» есть JSON (который, кстати, без проблем конвертируется в BSON).
> В то время как адекватных применений Tree — гораздо больше.
Попытка создать инструмент, который делает все, приводит к тому, что он делает все в равной степени плохо. В том смысле, что специализированный инструмент, справился бы с конкретной задачей значительно лучше.
Почему вы решили, что я его недооцениваю? XML хорошо показал себя в свое время, но сейчас ему находят более эффективные альтернативы. В IT все стремится к упрощению. Почему JSON стал так популярен? Потому, что он прост: не нужна никакая схема, не нужно ничего декларировать — просто используй.
>И идея разделения языка и формата — очень здравая
Разве я это отрицал? Я говорил лишь о том, что Tree не решает тех проблем, которые вы нашли в JSON. Во всяком случае, без использования схемы. А если использовать схему, то ваш формат усложняется. Причем это усложнение сразу нивелирует все его плюсы:
1. Он становится слишком неудобным для использования человеком
2. Он начинает конкурировать с BSON (так же «удобно» редактировать руками) и Protobuffers, где «сливает» вообще по всем параметрам.
Извините, но эти «ограничения» служат для удобства использования и никак не виляют на выразительность.
В то же время в Tree этого всего нет, а значит придется как-то это где-то специфицировать (как отличить сортированный от несортированного?). Введете TSD и Tree Schema?
Это не простота, это бедность.
> пачку управляющих символов
Эти подлежат «экранированию» по причине того, что просто так с клавиатуры их не ввести.
Остальные, действительно, ограничения, накладываемые форматом, здесь вы правы.
Идея использовать практически голые AST как формат хранения данных мне нравится.
Но то, что вы показываете — сильно недоработанная концепция.
И, пожалуй, его главная проблема — амбициозность разработчика, которая формирует соответствующее отношение к самому проекту.
>Если сразу показать
А если не показать, то человеку придется проматывать вниз, чтобы понять о чем вообще речь.
Либо уйти, не читая.
>Тут же я хотел сначала обрисовать недостатки известных форматов, подчеркнув, что в предлагаемом решении их нет. Вы же испортили себе всё впечатление :-)
Нет, не испортил. Таблицу я прочитал до того, как промотал вниз.
Почти в самый конец, потому как в пределах 4 (!!!) экранов не увидел ниодного примера этго чуда,
которое получило оценку 5 почти по всем пунктам
>Одним универсальным проще, чем двумя ограниченными
Чем ограничены эти два формата?
Как уже говорил, «списки», по сути, это вложенные JSON документы.
Массивы это просто синтаксис для таких документов, без необходимости ввода ключей, чтобы не писать в столбик ключи без значений, как вы это делаете в Tree (из примера ниже)
>На самом деле менее.
Вовсе нет. Что там пелена, что здесь.
>В нём сложно написать что-то нечитаемое или допустить синтаксическую ошибку.
Видимо из-за проблем с выразительным средствами.
Как же проблема с = перед значением, которую описала sferrka?
А хранение ключей, которую описал я выше?
А пробелы в ключе, про которые говорил PHmaster ниже?
> форматах экранировать приходится гораздо большее число символов.
У вас перенос строки, если верить примеру выше, просто заменяется на '=', что не сильно лучше \n
Поэтому количество символов, которые нужно экранировать у вас вовсе не меньше, если не больше из-за '='
>Я так понимаю вы намекаете на base64, base62
Нет, не намекаю. Строка в JSON является строкой условно, ничто не мешает вам хранить в ней blob
Нужно сначала показывать продукт, а уже потом сравнивать его с чем-то.
Пришлось промотать в самый низ, чтобы увидеть как выглядит это чудо.
>JSON и YAML для создания иерархий предлагают «списки» и «мапки». Не все структуры данных хорошо представимы с их помощью.
>В Tree есть только один тип узлов
Одним типом узлов, конечно проще описать чем двумя /sarcasm.
А если серьезно, то «списки» это вложенные JSON документы. Какая тут может быть проблема с представлением не понятно.
>Как минимум необходима разноцветная подсветка лексем. Очень помогает — автоформатирование, автодополнение и подсветка ошибок
Использовать Tree без всего этого будет не мене неудобно
>Отсутствие необходимости в экранировании и разэкранировании спецсимволов
Только для \n, видимо?
>Почти все текстовые форматы не совместимы с бинарными данными.
Простите? Что вам мешает хранить «бинарные данные» в JSON?
>В Tree нет комментариев
Мило
>Табуляция
Мило
>Универсальноть
Так и не объяснили что это значит.
Кроме того, как я понимаю, в качестве ключа нельзя использовать blob или даже произвольные «строки», например, включающие символ '='?
В остальном, если без всяких «языков на его основе», то выглядит неплохо. По сути просто json без лишних скобок и кавычек, что радует.
В шпицбергенском посёлке Лонгйир под эгидой ООН создаётся всемирный банк-хранилище посадочного материала всех сельскохозяйственных растений, существующих в мире. Собственный отсек в этом банке растений получит каждая страна.
Всемирное хранилище семян или как его чаще называют в СМИ «Хранилище судного дня» было построено в 2008 году.
Строительство хранилища, начатое в 2006 году, обошлось в 50 млн норвежских крон, что по сегодняшнему курсу составляет чуть больше 7,5 млн долларов, которые были выделены тремя норвежскими министерствами
Спасибо за ответ. С Ubuntu действительно не очень удачно получилось. В условиях, когда люди могут выбирать, жесткое навязывание чего-либо работает только если оно идет с самого начала.
Не холивара ради, но вы не могли бы объяснить в чем провал? Конечно, ИМХО, но из тех сред, что мне приходилось использовать Gnome 3 оказался самым удобным и продуманным, как с точки зрения управления, так и с точки зрения внешнего вида.
Конечно, некоторым он оказался непривычен, но, тем не менее, назвать его провальным нельзя.
>к провалу всего продукта
>Debian
Весьма спорное утверждение
>вначале потребуется жить под куполами
Я уже слышу пульс пробуждения
так же как и не нужно мне навязывать какие символы я могу использовать, а какие нет.
Вы прекрасно поняли что я имел ввиду имена узлов.
Я отлично понимаю что представляет из себя то, что вы показываете и ни через какую призму не смотрю.
Почему вы, вместо того, чтобы обратить внимание на то, что вам говорят, думаете, что вас не понимают и пытаетесь объяснить мне древовидную структуру мне не ясно.
1. Ограничение на ключи
С этим явно нужно что-то делать. Думаю, объяснять почему смысла нет.
2. Разделитель ключа и значения " ="
Вам, почему-то, кажется, что это совершенно неважная вещь. Но, я думаю, вы уже заметили, что многим это совершенно не нравится. Не потому, что это не привычно, а потому, что на это больно смотреть. Вы, наверняка, знаете это чувство, когда смотришь на код, который делает все как нужно, но выглядит «не так».
Кроме того, вы обосновываете это решение тем, что «это целый лишний пробел». Но, во-первых, в современных реалиях удобство программиста ставится выше эффективности кода (не могу сказать хорошо это или плохо, но это так). А во-вторых, вы все равно не сделаете здесь более эффективно, чем чисто бинарные форматы.
Так есть ли смысл ставить под удар «юзабельность», ради выигрыша нескольких байт?
3. Необходимость экранирования переноса строки в сырых данных.
Расходы на экранирование будут возрастать пропорционально объему этих данных. То же самое при извлечении этих данных. Здесь, кстати, есть и другая проблема: придется перевыделять память каждый раз, как мы дойдем до предела буффера, потому, что не известно сколько нужно еще считать
Решить это можно, например, введя спецификатор размера значения.
>Но получил популярность потому, что очень прост для ЯваСкрипта.
К чему вы это?
SAX
Не спорю, можно. Но несколько сложнее, взять хотя бы проблему выбора между атрибутом и дочерним элементом.
Хотя, пожалуй, вы правы.
Извините, что утомил вас. Не волнуйтесь, я помню, и это очевидно из его сравнение с JSON, XML, YAML.
Перефразирую: если формат не предоставляет достаточно конструкций сам по себе, то их придется где-то описывать. Пример с массивами: да, в JSON они нумеруются от 0 и только так. Но в Tree такого нет вообще. Нигде не написано, являются ли дочерние узлы упорядоченными или нет и какие им даются индексы. А это значит, что придется вводить новую спецификацию (схему), для того, чтобы это описать.
Если вы подразумеваете, что в чистом виде он никогда не будет использоваться, то презентуйте его как мета-формат.
>только на изучение каждого инструмента нужно время
Даже если описать все эти языки в рамках одного формата, это не делает изучение более простым
>таскать их все с собой не очень удобно
Как это отличается от все-в-одном?
>Плюс ещё и стыкуются они друг с другом плохо
Весьма спорное утверждение. Все зависит от конкретного случая.
Напомню, что сама идея, мне нравится. Мне не нравится её текущая реализация и тот факт, что эту реализацию пытаются выдать за «убийцу» вышеперечисленных форматов.
При том, что ей вы описываете что есть что. Если в языке нет необходимого минимума, то приходится описывать вообще все.
>В чём проблема запилить схему?
Только в том, что это нужно сделать. И чем раньше это «нужно» появится, тем хуже.
>Вы попробуйте сначала, а потом уже говорите о неудобности.
Пробовал уже. Как только вы для этого предложили нечто похожее на формы Бэкуса-Наура.
В связи с чем, кстати, появился вопрос: как вам идея использовать вместо вашего решения bison? Он несравнимо более гибок, да и реализация уже есть. Получаем сразу и описание формата и парсеры под все популярные языки.
>Всякие BSON и прочие бинарники имеют сильно ограниченное применение
Тем не менее в бинарной области они работать будут лучше чем та спецификация Tree, что вы показываете. А в «небинарной» есть JSON (который, кстати, без проблем конвертируется в BSON).
> В то время как адекватных применений Tree — гораздо больше.
Попытка создать инструмент, который делает все, приводит к тому, что он делает все в равной степени плохо. В том смысле, что специализированный инструмент, справился бы с конкретной задачей значительно лучше.
>И идея разделения языка и формата — очень здравая
Разве я это отрицал? Я говорил лишь о том, что Tree не решает тех проблем, которые вы нашли в JSON. Во всяком случае, без использования схемы. А если использовать схему, то ваш формат усложняется. Причем это усложнение сразу нивелирует все его плюсы:
1. Он становится слишком неудобным для использования человеком
2. Он начинает конкурировать с BSON (так же «удобно» редактировать руками) и Protobuffers, где «сливает» вообще по всем параметрам.
В то же время в Tree этого всего нет, а значит придется как-то это где-то специфицировать (как отличить сортированный от несортированного?). Введете TSD и Tree Schema?
Это не простота, это бедность.
> пачку управляющих символов
Эти подлежат «экранированию» по причине того, что просто так с клавиатуры их не ввести.
Остальные, действительно, ограничения, накладываемые форматом, здесь вы правы.
Идея использовать практически голые AST как формат хранения данных мне нравится.
Но то, что вы показываете — сильно недоработанная концепция.
И, пожалуй, его главная проблема — амбициозность разработчика, которая формирует соответствующее отношение к самому проекту.
А если не показать, то человеку придется проматывать вниз, чтобы понять о чем вообще речь.
Либо уйти, не читая.
>Тут же я хотел сначала обрисовать недостатки известных форматов, подчеркнув, что в предлагаемом решении их нет. Вы же испортили себе всё впечатление :-)
Нет, не испортил. Таблицу я прочитал до того, как промотал вниз.
Почти в самый конец, потому как в пределах 4 (!!!) экранов не увидел ниодного примера этго чуда,
которое получило оценку 5 почти по всем пунктам
>Одним универсальным проще, чем двумя ограниченными
Чем ограничены эти два формата?
Как уже говорил, «списки», по сути, это вложенные JSON документы.
Массивы это просто синтаксис для таких документов, без необходимости ввода ключей, чтобы не писать в столбик ключи без значений, как вы это делаете в Tree (из примера ниже)
>На самом деле менее.
Вовсе нет. Что там пелена, что здесь.
>В нём сложно написать что-то нечитаемое или допустить синтаксическую ошибку.
Видимо из-за проблем с выразительным средствами.
Как же проблема с = перед значением, которую описала sferrka?
А хранение ключей, которую описал я выше?
А пробелы в ключе, про которые говорил PHmaster ниже?
> форматах экранировать приходится гораздо большее число символов.
У вас перенос строки, если верить примеру выше, просто заменяется на '=', что не сильно лучше \n
Поэтому количество символов, которые нужно экранировать у вас вовсе не меньше, если не больше из-за '='
>Я так понимаю вы намекаете на base64, base62
Нет, не намекаю. Строка в JSON является строкой условно, ничто не мешает вам хранить в ней blob
Пришлось промотать в самый низ, чтобы увидеть как выглядит это чудо.
>JSON и YAML для создания иерархий предлагают «списки» и «мапки». Не все структуры данных хорошо представимы с их помощью.
>В Tree есть только один тип узлов
Одним типом узлов, конечно проще описать чем двумя /sarcasm.
А если серьезно, то «списки» это вложенные JSON документы. Какая тут может быть проблема с представлением не понятно.
>Как минимум необходима разноцветная подсветка лексем. Очень помогает — автоформатирование, автодополнение и подсветка ошибок
Использовать Tree без всего этого будет не мене неудобно
>Отсутствие необходимости в экранировании и разэкранировании спецсимволов
Только для \n, видимо?
>Почти все текстовые форматы не совместимы с бинарными данными.
Простите? Что вам мешает хранить «бинарные данные» в JSON?
>В Tree нет комментариев
Мило
>Табуляция
Мило
>Универсальноть
Так и не объяснили что это значит.
Кроме того, как я понимаю, в качестве ключа нельзя использовать blob или даже произвольные «строки», например, включающие символ '='?
В остальном, если без всяких «языков на его основе», то выглядит неплохо. По сути просто json без лишних скобок и кавычек, что радует.
Wikipedia
flashnord.com
Звучит очень круто. Сразу в голове возникает фантастический сюжет о двух связанных мирах, где птицы могут перелетать с одной планеты на другую.
Естественно если атмосфера здесь и существует, то разрежена так сильно, что атмосфера она лишь формально, но фантазировать то это не мешает.
Не холивара ради, но вы не могли бы объяснить в чем провал? Конечно, ИМХО, но из тех сред, что мне приходилось использовать Gnome 3 оказался самым удобным и продуманным, как с точки зрения управления, так и с точки зрения внешнего вида.
Конечно, некоторым он оказался непривычен, но, тем не менее, назвать его провальным нельзя.
>к провалу всего продукта
>Debian
Весьма спорное утверждение