Mr. Twister

Вопрос по программированию

{"PI": 3.14159, "PI": 5.0}
Кто читал книгу "Дизайн и эволюция языка Джаваскрипт", там объясняется, почему вот это - валидный JSON? Какая от этого может быть польза, кроме вреда?
Я не читал, но мнение имею. Это валидный JSON со значением PI = 5.0. Команды интерпретируются слева направа сверху вниз, последовательно. Кто сам себе злобный буратино и генерирует такие смешные JSON'ы, overwrite'ящие предыдущие значения, сам виноват.
Ключевая идея к понимаю, что это валидный джейсон состоит в том, что джейсон это не сериализованная структура данных, как может показаться на первый взгляд, а всего лишь код на javascript.
А почему полезно парсить заведомо бессмысленный код без даже предупреждений?
А откуда парсер знает, что он бессмысленный? Может быть, overwritten значения используются в качестве полезных комментариев? или, скажем, хранят полезную историю последовательных модификаций?
Почему полезно не иметь синтаксиса для комментариев - это еще один вопрос, смежный.
В ответ на это, конечно же, есть смежный вопрос с другой стороны: почему полезно не менять формат, если его можно не менять.
Так это же новый стандарт, который сразу так сделали в полном объеме. Нельзя объяснить желанием совместимости с чем-то старым.
JSON? Я не изучал историю детально, но я сомневаюсь, мне кажется, он всё-таки естественно проэволюционировал из javascript'а (который долгое время был скриптовой поделкой, которую никто не рассматривал всерьёз).

Мне кажется, надо стараться видеть в людях лучшее, и при прочих равных предпочитать объяснения, не основанные на людских пороках (таких как невнимательность, пофигизм, глупость, сладкое садистское желание испортить жизнь инженерам из будущего, которые будут ковырять баги и краевые случаи, и т.п.)
Я именно подозреваю лучшее, даже спросил - может, кто знает, в чем оно заключается.
Я думаю, причины историчекие или compatibility.

Могу придумать причину "чтобы проще было написать парсер" (не нужно проверять на уникальность ключей, типа, сортировать или хэшировать), но это какая-то очень слабая и натянутая причина, мне трудно в неё поверить.
Может быть есть какой-то странный юс-кейс, когда намного удобнее дописывать новые значения в конец, таким образом эффективно изменяя старые, но при этом редактировать всё целиком накладно или невозможно в данной ситуации. Конкретику мне придумать сложно.
если JSON это код то в нем должны поддерживаться комментарии
прицепом тот же вопрос по поводу присваивания вместо сравнения.
Ну очевидно же. Для реализации парсера, живущего в тяжёлых условиях (мало памяти и/или CPU clocks), которому из-за этого тяжело проверять уникальность.
Нет, совершенно. Более того, это типа общее место.
Как же это может быть? Парсер все равно должен развернуть всю структуру и каждый атом положить на свое место. И при этом у него не хватает сил посмотреть, что на данном месте уже что-то лежит? Одну JNZ инструкцию сэкономили?
Парсер может быть stream, при этом он ничего не разворачивает, только выдает a sequence of events (ну, однобитный стек он может держать для валидации, но это совсем не "разворачивает"). Вот пример парсера, который хоть и как бы разворачивает, но делает это без e.g. malloc-ов и ничего не зная о таких стурктурах данных, как hash и set.
Хм, про него говорят, что он вообще ошибки не детектирует. Jsmn is missing [...] but instead is designed to be robust (it should work fine even with erroneous data). Т.е. он и так уже нестандартный. Если бы мой пример в стандарте был заявлен как erroneous, на качестве jsmn это бы не сказалось.
Ну да, so what? На качестве валидирующих парсеров с архитектурами такого типа сказалось бы очевидным образом.
Ну, интересно, есть в результате, или нет. Обычно, когда в стандарте какая-то на первый взгляд шокирующая глупость, то можно получить объяснение вида "к сожалению, иначе широко распространенный X сломался бы".