Здравствуйте, vdimas, Вы писали:

Отвечу только по ключевым пунктам.

По поводу вложенного Optional мне добавить нечего.

По поводу бинарной сериализации. Я не понимаю, зачем ты в разговоре постоянно скачешь с системы типов IDL на бинарную сериализацию и обратно. Они связаны конечно, но далеко не так прямо, как ты это хочешь представить. Битовое кодирование опциональных полей — это всего лишь деталь реализации, оптимизация, и никакого отношения к исходному вопросу не имеет.

Ну и отвечу на наезды по поводу IDL. Так как это оффтопик, то под кат.

	Скрытый текст
	Прежде всего, в 2017 году странно считать, что разработка DSL и IDL вообще это rocket science. Зачем нужен IDL? Ты все сводишь к протоколам коммуникации, это лишь часть айсберга. Мы занимаемся играми средних размеров (цикл разработки один-три года до релиза, и затем поддержка). Играм нужен инструментарий — дизайнерам, локализаторам, создателям контента, аналитикам, коммьюнити-менеджерам, администраторам. Писать их под каждый проект — неокупаемо. Для AAA-игр — возможно да, для нас — нет. Нужен проектно-независимый инструментарий. Кому-то нужен код, сгенерированный из IDL, кому-то схема, подтягиваемая на лету. Без единой модели данных, описанной в IDL, все развалится, потеряет актуальность. Важная часть моей работы — оптимизация workflow. Когда к нам приходят новые сотрудники, я спрашиваю их, как они работали раньше. Вот на примере дизайнеров. "Мы редактировали XML и коммитили в гит" — это самый печальный ответ, но он же — самый частый. Основные затыки дизайнерского worlflow — это отстойные инструменты (само собой), это система контроля версий (как только вы смешали работу дизайнера с работой программиста в одном репозитории — вы замедлили и их, и себя), это устаревание инструментария (когда протокол изменился, и дизайнер отдыхает, обновляясь или ожидая обновления), это необходимость общения между дизайнером и программистом, это цикл "попробовал — увидел результат", и это плохая обратная связь в случае ошибок. У нас ничего этого нет. Они работают в своем инструментарии, их схема всегда актуальна, валидация всегда качественна, и все их изменения применяются на живом сервере для всех текущих клиентов по нажатию кнопки "сохранить". А ведь в этом нет ничего особенного, это всего лишь результат использования IDL. Разработка начинается с IDL и завязана на IDL. Он должен быть удобным, и кодогенерация должна быть гибкой. ASN.1? Нет. Он хорошо подходит для описания стандартов сетевых протоколов, но это же совсем другая задача. Какие есть альтернативы? Из самого известного — Google protobuf, Apache Thrift, с недавних времен — Microsoft Bond. Мы начали с protobuf. Это было лет десять назад, все могло измениться. Но тогда генерируемый код был ужасен. Система типов — бедновата, даже map/dict не было. Плюс он заточен на версионность, что дает значительный оверхед по размеру пакетов — так как даже для required пакетов записывается числовой тэг. Генерации в JSON — не было. Расширение кодогенератора — адские муки. На одном проекте промучались, другой начали с создания своего IDL. Реализация прототипа на Nemerle заняла две недели. Человекогоды разработки? Видимо ты перепутал с годами использования. Да, IDL развивался, но благодаря использованию Nemerle (а потом Nitra) — с минимальными трудозатратами. Правильные инструменты всегда решают.

V>Самая главная у тебя проблема — это много недоговариваний, преувеличений и откровенного вранья в итоге.
А у тебя — это хамство. Я открыт критике, но ты уж слишком много на себя берешь. Увольнения, обманутые инвесторы, вранье — ну не на базаре же.