Парсер JSON, написанный на D, стал самым быстрым парсером JSON в мире

Да это на лоре всегда так... главное - срач и крики про своё болото.

Посмотрел по диагонали.

Парсер JSON, написанный на D, стал самым быстрым парсером JSON в мире (комментарий)

Парсер JSON написанный на D стал самым быстрым парсером JSON в мире!

По версии какого-то Кости. Что это делает на главной?

У меня в таких случаях возникает два вопроса: 'и что?' и 'за счет чего?'.

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

И как они этого добились, где сэкономили, почему другие этого не реализовали, завязано ли это на особенности самого Д?

А в текущем виде это имхо так себе новость.

Servo не?

Python тормоз

JSON уродлив. JSON не поддерживает бинарные строки. Приходится рекурсивно кодировать в base64, а потом декодировать. Ужас

Просто для примера, а как бы это выглядело? Представление бинары в тексте, без предварительного кодирования в base64. Где-то это уже реализовано?

Тогда уж на PHP или basic'е.

Ну хоть для чего-то Д пригодился :)

Скажите ему: http://bsonspec.org/

For ex­ample, BSON has a Date type and a BinData type.

P.S. Есть молодой CBOR, RFC 7049, только пока малораспространен.

Поставят Project Lombok и будут делать тоже самое, только аннотациями

А вот ключ, как список - там такого нет

А так:

QList <quint8> list;
...
settings->beginWriteArray( "prefix" );
for (int i = 0; i < list.count(); ++i) {
    settings->setArrayIndex(i);
    settings->setValue( "name", list.at(i) );
}
settings->endArray();

?

как то геморно :) Но работает, да.

Вообще, предложенный мной вариант (кроме того, что занимает меньше строк), позволяет и считывать массивы как они есть

a.value('key')

(для плюсов дополнительно надо скастовать в список из QVariant).

утино-типизированного js

Это вы откуда взяли что в js утиная типизация?

welcome ^_^

lua

Это вы откуда взяли что в js утиная типизация?

https://en.wikipedia.org/wiki/JavaScript
«Typing discipline dynamic, duck»

Так-же как я понял D Gdc это компиляции D с помощью GCC? То-есть теоретически можно сделать такой код на С++ или С который после компиляции будет бинарно идентичен D Gdc Fast?

Нет. GCC это далеко не только C/С++, он используется как бэкенд для множества языков, и это вовсе не значит, что результат будет идентичен.

Всем. Кстати, а что произойдёт, если я напишу, а потом отсортирую строки как мне нравится? Только не говори, что придётся все индексы руками перебивать.

Зачем строки перебивать руками? Вы создаете проблему там, где ее нет.

Зачем строки перебивать руками? Вы создаете проблему там, где ее нет.

А мы тут о программировании ради программирования? Софтом потом кто-то будет пользоваться. И этот кто-то будет редактировать конфиги, в том числе руками. При этом совершенно непредсказуемым образом. Если нужен просто какой-то формат сериализованные объекты гонять между процессами, то без разницы, хоть JSON, хоть Protobuf, хоть азбука Морзе. Но ранее прозвучали слова о человекочитаемости, и тут без рук не обойдётся.

А мы тут о программировании ради программирования?

Мы говорим о том, что формат ini вполне способен хранить иерархию.

Софтом потом кто-то будет пользоваться. И этот кто-то будет редактировать конфиги, в том числе руками.

Это его право, пусть редактирует.

При этом совершенно непредсказуемым образом.

Да, действия обезьяны сложно предсказать. Только как это мешает хранить иерархию в ini-формате?

Если нужен просто какой-то формат сериализованные объекты гонять между процессами, то без разницы, хоть JSON, хоть Protobuf, хоть азбука Морзе.

Кто-то с этим спорил?

Но ранее прозвучали слова о человекочитаемости, и тут без рук не обойдётся.

Если у человека растут руки из жопы, то никакой формат не спасет от ошибки.

Нет. GCC это далеко не только C/С++, он используется как бэкенд для множества языков, и это вовсе не значит, что результат будет идентичен.

Но ведь оба по идеи должны использовать одно и тот-же промежуточное представление кода GCC(По типу как в LLVM это IR)?

Нет, ну ты, конечно, молодец. Берешь самый тормознутейший из парсеров - Jackson, и его бенчишь. Жексон - он не для скорости, жексон - он для фич. Ты gson'ом, хотя бы, посмотри. Или всякими там ультралегкими парсерами на parboiled.

Нет, GCC принципиально отличается от LLVM (по мнению многих - не в лучшую сторону) именно в этом моменте. Все же GСС - это компилятор, а LLVM, не будем забывать - Low Level Virtual Machine.

D не может быть быстрым, если там, конечно, парсер на ассемблере не запустили.

Лучше бы для rust написали хороший html парсер

servo?

D не может быть быстрым, если там, конечно, парсер на ассемблере не запустили.

Судя по всему типичный пример «Не читал, но осуждаю!». С чего это такой категоричный вывод-то?

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

https://github.com/dzidzitop/libafc/blob/master/src/afc/json.hpp

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

вывод: юзер - кусок говна

Первый вменяемый эклипс ...

До сих пор не вышел. Оно в большинстве случаев не может в code-complition, рефакторинг (и возможно что-то ещё) при наличии ошибок в коде. В отличие от IDEA, например.

Кто бы сомневался. ASN.1 и BER encoding рулят. А самым говёным в истории человечества методом кодирования является XML - что почему-то не мешает этому убогому высеру больного разума быть доминирующим способом кодирования структур данных в IT.

Ну вот и ответ. Я думал, хоть на арме поднимется...

Data size limited by available contiguous virtual memory

А это вообще эпично. Мне при чтении файла теперь надо учитывать, какой там у нас счас размер непрерывной виртуальной памяти можно забрать?

обгоняя парсер на Python в более чем 6 раз по памяти и в 14 раз по скорости

Я всегда говорил - говно этот ваш питон. Для того, чтобы быстро закодить скрипт - есть perl, а чтобы закодить что-то быстродействующее - C, C++ ну вот сейчас ещё D. Ну, на худой конец, жабка.

Мы говорим о том, что формат ini вполне способен хранить иерархию.

Теоретически можно представлять конфиги хоть в brainfuck. Но мы же говорим о практике.

Да, действия обезьяны сложно предсказать. Только как это мешает хранить иерархию в ini-формате?

Мы ведь говорим о формате, проверенном на практике. А я только в этом треде увидел несколько вариантов хранить иерархию и массивы.
У меня к тебе пару вопросов: парсер должен поддерживать все эти варианты? А реальный человек? Можно ли их комбинировать в одном файле? В одной структуре

Если у человека растут руки из жопы, то никакой формат не спасет от ошибки.

Мне кажется тут уместна аналогия с выстрелом себе в ногу. У JSON довольно простые правила: ключ:значение, элементы разделять запятой, массив ложить в [], словари в {}, цифры лучше писать без кавычек. Сколько займёт описания всех вариантов иерархии ini, которые были в данном треде?

Во-первых, аббревиатура уже давно не расшифровывается, это просто название из четырёх букв. Во-вторых, принципиально LLVM отличается от GCC скорее в том моменте, что LLVM — это больше модульная библиотека, а GCC — это больше монолитная программа (и Столлман из принципа оставляет его монолитным). В-третьих, у GCC тоже есть универсальное промежуточное представление, с которым работает его бекэнд, и в которое перегоняются все языки, с которыми работает GCC; просто Столлман против того, чтобы это представление можно было сдампить и использовать вне происходящего здесь и сейчас процесса компиляции.

JSON, на мой вкус, человекочитаем довольно условно. Его суперсет — YAML — много лучше читается

Начать надо с того, что yaml делал такой же упоротый дебил, что и пестон - НА ОТСТУПАХ! Соотв. перенос фрагментов кода становится тем ещё весельем.
Во-вторых, JSON уже стандарт де-факто - отгадайте почему? ОН УДОБЕН. Он намного «чище» XMLя. Он типизируем (можно к имени поля добавлять тип). Его можно ужимать (давая краткие синонимы полям и выводя без пробелов) и всё это в одну строку. Yaml тут выглядит как калека, про которого только сейчас вспомнили - где вы были во времена XML?? :)

Как вы _этим_ пользуетесь? Это же АД.

сказал человек, сам пользующийся _этим_

Так-то да, но речь шла немного не об этом, а о том, что код на разных языках, скормленный одному и тому же бэкенду, выдаст все же разные результатыю

Мне джава не по масти.

это потому что твоя масть петушиная.

Мамку твою.

Мы говорим о том, что формат ini вполне способен хранить иерархию.

Теоретически можно представлять конфиги хоть в brainfuck. Но мы же говорим о практике.

Зачем вы передергиваете?

Мы ведь говорим о формате, проверенном на практике. А я только в этом треде увидел несколько вариантов хранить иерархию и массивы.

Сколько еще чудных вещей вам откроется с возрастом.

У меня к тебе пару вопросов: парсер должен поддерживать все эти варианты?

Нет, задача ini-парсера выполнять свою задачу.

А реальный человек?

Что реальный человек?

Можно ли их комбинировать в одном файле?

Что значит комбинировать? Формат ini предполагает хранение пар key=value. Формируя правильный key можно хранить данные с любой иерархией. Формируя правильный value вы можете хранить там любые данные. Это никак не влияет ни на парсер, ни на формат.

В одной структуре

Это и есть одна структура.

Сколько займёт описания всех вариантов иерархии ini, которые были в данном треде?

Все вами перечисленное легко хранить и в ini. Но да, нужны руки и голова.

Ты недооценил упоротость Yaml - там не отступы, а выравнивания пробелами. И таб невалиден для отступа

Таб невалиден для отступа, Карл!

джава не по масти.

А туда ли ты зашел?

У меня к тебе пару вопросов: парсер должен поддерживать все эти варианты?

Нет, задача ini-парсера выполнять свою задачу.

А реальный человек?

Что реальный человек?

Я вижу ты решил прикинуться шлангом. Но я тебя переспрошу подругому: нахера нужен формат, у которого не написано в спеке как хранить ерархию и массивы, да и самой спеки нет. Каждый воротит что ему горазд, при редактировании конфига каждой программы пользователь должен вспоминать какой же из вариантов иерархии используют разработчики программы, или свой велосипед, который нужно ещё и изучить. Короче, пока нет RFC его даже форматом назвать нельзя. Под DOS и оффтопом когда использовалось, но оно уже 20 лет как объявлено deprecated самой MS, но некоторых до сих пор не отпускает ностальгия. Синдром утёнка.

С другой стороны, для JSON есть RFC и реализация в либах под любой недоязычёк и платформу. Например, в iOS JSON<->нативные структуры данных преобразуются вызовом одного метода. Более того, некоторые либы даже это упрощают и принимают на вход и отдают нативные объекты, а по сети гоняют JSON.

В случае с INI нужно вручную ререализовывать чтение/запись конфига под каждый INI «BydloProga Edition». Если не ценишь пользователей и заставляешь их использовать свой неудобный формат, так пожалей хотя бы своих коллег программистов, которые захотят писать GUI (WUI, TUI) для настроек твоей проги. Хотя, по большому счёту, программы пишутся для людей и удобство пользователя должно быть на первом месте.

В связи с этим хочу направить всю боль разработчиков cPanel, Webmin, ISPConfig и им подобных в твой анус!

Я вижу ты решил прикинуться шлангом.

Мне кажется, что шланг тут вы. Я лишь сказал, что plain-ini-file позволяет хранить и иерархию, и массивы.

Но я тебя переспрошу подругому: нахера нужен формат, у которого не написано в спеке как хранить ерархию и массивы, да и самой спеки нет.

Мне привести вам всех нуждающихся поименно?

Короче, пока нет RFC его даже форматом назвать нельзя.

Еще раз key=value. Плюс категории/группы/секции. Какая еще спека вам нужна?
По вашему спека на нечитабельный json описывает имена ключей? Если нет, то как пользователь будет редактировать руками конфиг, не зная имен и соответствий типов?

Под DOS и оффтопом когда использовалось, но оно уже 20 лет как объявлено deprecated самой MS, но некоторых до сих пор не отпускает ностальгия.

Некая компания сказала, что использовать ini формат больше не будет. Все, для дурачков этот формат умер.

Синдром утёнка.

Этот синдром у вас в голове. Один дурачок сказал, что ini плох, а другой за ним повторяет.

Например, в iOS JSON<->нативные структуры данных преобразуются вызовом одного метода. Более того, некоторые либы даже это упрощают и принимают на вход и отдают нативные объекты, а по сети гоняют JSON.

Много конфигов под ios/android вы отредактировали руками?

В случае с INI нужно вручную ререализовывать чтение/запись конфига под каждый INI «BydloProga Edition».

Формат ini прост как грабли. Если вам кажется, что реализация этого формата слишком сложная, то профессия программиста не для вас.

Если не ценишь пользователей и заставляешь их использовать свой неудобный формат,

Пользователю насрать, какой формат хранения профайла используется в приложении. Пользователь пользуется приложением.

которые захотят писать GUI (WUI, TUI) для настроек твоей проги.

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

https://doc.rust-lang.org/std/simd/

Прикольно. Вот только пока unstable.

Вот ты вроде хорошие, адекватные комментарии оставляешь.

Но конкретно сейчас ты защищаешь сущую глупость. Зачем в ini воротить цирк со специальными ключами, если он для этого НЕ предусмотрен? Там один уровень. И для своего одного уровня этот формат хорош.