Сообщение Re[8]: Опциональные типы от 24.02.2017 22:14
Изменено 24.02.2017 22:15 vdimas
Re[8]: Опциональные типы
Здравствуйте, meadow_meal, Вы писали:
_>По поводу вложенного Optional мне добавить нечего.
Тебе ответить нечего, вестимо, потому что в 3-х соснах заплутал.
Рядом коллега D. Mon на пальцах абсолютно правильно объяснил, что такое Optional/Nullable.
Это когда берется всё множество значений некоего типа и к нему добавляется еще одно СПЕЦИАЛЬНОЕ значение (некоего типа, представленного единственным значением), образуя тем самым новый тип — алгебраическую сумму исходных типов.
Прямо отсюда должно стать понятным, если под это СПЕЦИАЛЬНОЕ значение можно выделить некое значение из исходного диапазона, то надобность складывать типы резко отпадает. Трюк стар как мир, а поди ж ты.
_>По поводу бинарной сериализации. Я не понимаю, зачем ты в разговоре постоянно скачешь с системы типов IDL на бинарную сериализацию и обратно.
Потому что IDL не предназначена для эффективной сериализации by design, вестимо.
Собсно, поэтому появился ASN.1
А еще потому, что IDL описывает синхронные вызовы, где асинхронность лишь эмулируется через возвращаемый void.
Кароч. ЗАставляешь толкать те банальности, что вот уже десяток с лишним лет как самый последний разработчик сетевых приблуд осознал, что в сети рулит просто асинхронный обмен сообщениями, т.е. встречные трафики двух ендпоинтов можно рассматривать как независимые/несинхронизированные.
Именно поэтому в ASN.1 описываются сообщения (последовательности примитивных и составных типов данных), но не интерфейсы объектов.
_>Они связаны конечно, но далеко не так прямо, как ты это хочешь представить.
Рассуждения человека, далекого от предметной области.
Это в ASN.1 прямо стандартом вводится абстрагирование самого описания данных от способов (профилей) их кодирования. На сегодня есть 4 популярных профиля кодирования.
А вот в IDL, например, в CORBA-IDL или COM-IDL бинарная сериализация прибита гвоздями ко всему. И абсолютно никакие оптимизации недопустимы, потому что есть однозначный маппинг описания на содержимое потока.
_>Битовое кодирование опциональных полей — это всего лишь деталь реализации, оптимизация, и никакого отношения к исходному вопросу не имеет.
В IDL нет битового описания опциональных полей. Если описывать union, то минимальный дискриминатор будет 1 байт. А если взять хотя бы типизированный enum в кач-ве дискриминатора (это удобно и разумно), то это будет 2 байта. Вот такие дела.
_>Прежде всего, в 2017 году странно считать, что разработка DSL и IDL вообще это rocket science.
DSL — нет, ведь они бывают разные по сложности.
Например у меня как-то ушло ровно два часа на несложный язык.
(понятно, что не первый в репертуаре + визуальный инструмент отладки грамматики + кодогенератор, но это просто показатель несложности такой работы в 2017-м)
А вот IDL — да, это рокет саенс.
Т.е., ты вводишь всех в заблуждение. По какой причине? — ХЗ.
Может плохо понимаешь, что есть IDL, но тебе нравится аббревиатура...
А может понимаешь, но хочется, чтобы звучало громче (именно это я имел ввиду, говоря, что ты врёшь).
_>Зачем нужен IDL?
IDL — это инфраструктура:
(a) для сериализации/десериализации посылки сообщений объектам;
(b) организация принципов identity объектов, прозрачной для любого языка, на который происходит маппинг.
Последнее означает, что можно делать вызовы методов объектов, независимо от их расположения. Программисту не обязательно знать, где находится объект: в текущем аппартменте текущего процесса, в другом аппартменте, в другом процессе или на другой машине.
Ты уже понял, к чему я клоню? Последнее означает, что никакой ClanID не нужен.
В системе IDL можно просто присвоить ссылку на новый клан или null, если игрок вышел из клана.
Т.е. можно писать прямо вот так на серваке (на языке программирования сервака):
И ву-а-ля. Всё будет прекрасно работать само на нормальном транспорте. И передастся на клиента. Т.е. такой код мог выполнятся на, скажем C#-серваке, а в реальности null будет присвоен объекту на C++-клиенте. Вот что такое IDL.
Т.е., твоё ClaID лично мне намекает, что никакого (b) у вас там нет и в помине, а есть лишь некое (a).
Так шта, теперь, с этими новыми знаниями, ты можешь вернуться и перечитать мой сообщение еще раз.
Тогда, может быть, тебе станет понятней, что именно я тебе писал и почему я всё это писал.
Потому что вот всем этим ответом ты показал, что не понял ни слова.
_>Ты все сводишь к протоколам коммуникации, это лишь часть айсберга. Мы занимаемся играми средних размеров (цикл разработки один-три года до релиза, и затем поддержка). Играм нужен инструментарий — дизайнерам, локализаторам, создателям контента, аналитикам, коммьюнити-менеджерам, администраторам. Писать их под каждый проект — неокупаемо. Для AAA-игр — возможно да, для нас — нет. Нужен проектно-независимый инструментарий. Кому-то нужен код, сгенерированный из IDL, кому-то схема, подтягиваемая на лету. Без единой модели данных, описанной в IDL, все развалится, потеряет актуальность.
Бла-бла, детсад.
ДУмаешь у других в области сетевых технологий как-то по-другому?
Сорри, но ты, блин, пишешь как вчерашний студент. Я бы дал не более 27-ми лет.
Только не пойми неправильно — быть вчерашним студентом ни в коем случае НЕ зазорно. Зазорно при этом игнорить накопленные практики, отказываться учиться и уж тем более должно быть зазорно надуваться по пустому поводу. Потому что как следствие обязательно идёт отсутствие развития — а это смерть специалиста и обман инвесторов. ))
_>Важная часть моей работы — оптимизация workflow.
Тогда ты тем более должен был тщательней провести исследования, как подобные задачи в принципе решают.
_>А ведь в этом нет ничего особенного, это всего лишь результат использования IDL.
У вас не IDL, у вас некий DSL.
_>Разработка начинается с IDL и завязана на IDL. Он должен быть удобным, и кодогенерация должна быть гибкой. ASN.1? Нет. Он хорошо подходит для описания стандартов сетевых протоколов, но это же совсем другая задача.
Потому что ты не понимаешь слова "абстракция", вестимо.
Как ты думаешь, что означают термины front-end и back-end?
В общем, если не в курсе — подсмотришь их самостоятельно.
Так вот. На front-end-е может исопльзоваться какой-нить простенький проблемно-ориентированный DSL. Его даже не зазорно делать уникальным для каждого отдельного проекта. Не с 0-ля, ес-но, а на каком-то общем DSL-ядре.
А вот для back-end-a для сетки надо брать что-то надёжное готовое.
Потому что иначе надо будет потратить заметное кол-во человекочасов для рождения альтернативы, как минимум не уступающей в кач-ве и надежности уже имеющимся разработкам.
Я предложил ASN.1 ровно по одной причине — это пример сугубо текстового описания на выходе, под которое можно выбирать профили кодирования. Именно этим мне ASN.1 и симпатичен. Но это не принципиально, ес-но, на сегодня есть куча альтернатив.
_>Какие есть альтернативы?
Их много.
Подойдёт любой с текстовым описанием.
_>Мы начали с protobuf. Это было лет десять назад, все могло измениться. Но тогда генерируемый код был ужасен. Система типов — бедновата, даже map/dict не было.
Вот чтобы так не вляпываться, для любой технологии сначала идёт период evaluation.
Причем, желательно одновременно оценивать минимум 3 технологии.
_>На одном проекте промучались, другой начали с создания своего IDL. Реализация прототипа на Nemerle заняла две недели. Человекогоды разработки? Видимо ты перепутал с годами использования. Да, IDL развивался, но благодаря использованию Nemerle (а потом Nitra) — с минимальными трудозатратами. Правильные инструменты всегда решают.
В вашем случае решили не инструменты, а случайность.
Потому что удобных инструментов для разработки своих языков полно.
Скажи честно — сколько времени ты потратил на эксперименты с ANTLR?
Даже совершенно неопытный в деле разработки языков разработчик может за пару дней на ANTLR разработать свой язык описания сетевых сообщений.
А уж опытному (всего второй такой язык в репертуаре) — это дело единиц часов.
V>>Самая главная у тебя проблема — это много недоговариваний, преувеличений и откровенного вранья в итоге.
_>А у тебя — это хамство. Я открыт критике, но ты уж слишком много на себя берешь. Увольнения, обманутые инвесторы, вранье — ну не на базаре же.
Да, да. Проходили.
Сначала малость увлекаемся, а потом строим из себя невинную овечку...
Вот это моё сообщение было абсолютно нейтральным, т.е. сугубо техническим:
http://www.rsdn.org/forum/philosophy/6706569.1
Почитай, что и в каком виде ты там наотвечал.
Тебе был предложен тон делового обсуждения.
Ты в ответ предложил цирк.
Оууукееей. :-
_>По поводу вложенного Optional мне добавить нечего.
Тебе ответить нечего, вестимо, потому что в 3-х соснах заплутал.
Рядом коллега D. Mon на пальцах абсолютно правильно объяснил, что такое Optional/Nullable.
Это когда берется всё множество значений некоего типа и к нему добавляется еще одно СПЕЦИАЛЬНОЕ значение (некоего типа, представленного единственным значением), образуя тем самым новый тип — алгебраическую сумму исходных типов.
Прямо отсюда должно стать понятным, если под это СПЕЦИАЛЬНОЕ значение можно выделить некое значение из исходного диапазона, то надобность складывать типы резко отпадает. Трюк стар как мир, а поди ж ты.
_>По поводу бинарной сериализации. Я не понимаю, зачем ты в разговоре постоянно скачешь с системы типов IDL на бинарную сериализацию и обратно.
Потому что IDL не предназначена для эффективной сериализации by design, вестимо.
Собсно, поэтому появился ASN.1
А еще потому, что IDL описывает синхронные вызовы, где асинхронность лишь эмулируется через возвращаемый void.
Кароч. ЗАставляешь толкать те банальности, что вот уже десяток с лишним лет как самый последний разработчик сетевых приблуд осознал, что в сети рулит просто асинхронный обмен сообщениями, т.е. встречные трафики двух ендпоинтов можно рассматривать как независимые/несинхронизированные.
Именно поэтому в ASN.1 описываются сообщения (последовательности примитивных и составных типов данных), но не интерфейсы объектов.
_>Они связаны конечно, но далеко не так прямо, как ты это хочешь представить.
Рассуждения человека, далекого от предметной области.
Это в ASN.1 прямо стандартом вводится абстрагирование самого описания данных от способов (профилей) их кодирования. На сегодня есть 4 популярных профиля кодирования.
А вот в IDL, например, в CORBA-IDL или COM-IDL бинарная сериализация прибита гвоздями ко всему. И абсолютно никакие оптимизации недопустимы, потому что есть однозначный маппинг описания на содержимое потока.
_>Битовое кодирование опциональных полей — это всего лишь деталь реализации, оптимизация, и никакого отношения к исходному вопросу не имеет.
В IDL нет битового описания опциональных полей. Если описывать union, то минимальный дискриминатор будет 1 байт. А если взять хотя бы типизированный enum в кач-ве дискриминатора (это удобно и разумно), то это будет 2 байта. Вот такие дела.
_>Прежде всего, в 2017 году странно считать, что разработка DSL и IDL вообще это rocket science.
DSL — нет, ведь они бывают разные по сложности.
Например у меня как-то ушло ровно два часа на несложный язык.
(понятно, что не первый в репертуаре + визуальный инструмент отладки грамматики + кодогенератор, но это просто показатель несложности такой работы в 2017-м)
А вот IDL — да, это рокет саенс.
Т.е., ты вводишь всех в заблуждение. По какой причине? — ХЗ.
Может плохо понимаешь, что есть IDL, но тебе нравится аббревиатура...
А может понимаешь, но хочется, чтобы звучало громче (именно это я имел ввиду, говоря, что ты врёшь).
_>Зачем нужен IDL?
IDL — это инфраструктура:
(a) для сериализации/десериализации посылки сообщений объектам;
(b) организация принципов identity объектов, прозрачной для любого языка, на который происходит маппинг.
Последнее означает, что можно делать вызовы методов объектов, независимо от их расположения. Программисту не обязательно знать, где находится объект: в текущем аппартменте текущего процесса, в другом аппартменте, в другом процессе или на другой машине.
Ты уже понял, к чему я клоню? Последнее означает, что никакой ClanID не нужен.
В системе IDL можно просто присвоить ссылку на новый клан или null, если игрок вышел из клана.
Т.е. можно писать прямо вот так на серваке (на языке программирования сервака):
gamer.setClan(newClan);
// или
gamer.setClan(null);И ву-а-ля. Всё будет прекрасно работать само на нормальном транспорте. И передастся на клиента. Т.е. такой код мог выполнятся на, скажем C#-серваке, а в реальности null будет присвоен объекту на C++-клиенте. Вот что такое IDL.
Т.е., твоё ClaID лично мне намекает, что никакого (b) у вас там нет и в помине, а есть лишь некое (a).
Так шта, теперь, с этими новыми знаниями, ты можешь вернуться и перечитать мой сообщение еще раз.
Тогда, может быть, тебе станет понятней, что именно я тебе писал и почему я всё это писал.
Потому что вот всем этим ответом ты показал, что не понял ни слова.
_>Ты все сводишь к протоколам коммуникации, это лишь часть айсберга. Мы занимаемся играми средних размеров (цикл разработки один-три года до релиза, и затем поддержка). Играм нужен инструментарий — дизайнерам, локализаторам, создателям контента, аналитикам, коммьюнити-менеджерам, администраторам. Писать их под каждый проект — неокупаемо. Для AAA-игр — возможно да, для нас — нет. Нужен проектно-независимый инструментарий. Кому-то нужен код, сгенерированный из IDL, кому-то схема, подтягиваемая на лету. Без единой модели данных, описанной в IDL, все развалится, потеряет актуальность.
Бла-бла, детсад.
ДУмаешь у других в области сетевых технологий как-то по-другому?
Сорри, но ты, блин, пишешь как вчерашний студент. Я бы дал не более 27-ми лет.
Только не пойми неправильно — быть вчерашним студентом ни в коем случае НЕ зазорно. Зазорно при этом игнорить накопленные практики, отказываться учиться и уж тем более должно быть зазорно надуваться по пустому поводу. Потому что как следствие обязательно идёт отсутствие развития — а это смерть специалиста и обман инвесторов. ))
_>Важная часть моей работы — оптимизация workflow.
Тогда ты тем более должен был тщательней провести исследования, как подобные задачи в принципе решают.
_>А ведь в этом нет ничего особенного, это всего лишь результат использования IDL.
У вас не IDL, у вас некий DSL.
_>Разработка начинается с IDL и завязана на IDL. Он должен быть удобным, и кодогенерация должна быть гибкой. ASN.1? Нет. Он хорошо подходит для описания стандартов сетевых протоколов, но это же совсем другая задача.
Потому что ты не понимаешь слова "абстракция", вестимо.
Как ты думаешь, что означают термины front-end и back-end?
В общем, если не в курсе — подсмотришь их самостоятельно.
Так вот. На front-end-е может исопльзоваться какой-нить простенький проблемно-ориентированный DSL. Его даже не зазорно делать уникальным для каждого отдельного проекта. Не с 0-ля, ес-но, а на каком-то общем DSL-ядре.
А вот для back-end-a для сетки надо брать что-то надёжное готовое.
Потому что иначе надо будет потратить заметное кол-во человекочасов для рождения альтернативы, как минимум не уступающей в кач-ве и надежности уже имеющимся разработкам.
Я предложил ASN.1 ровно по одной причине — это пример сугубо текстового описания на выходе, под которое можно выбирать профили кодирования. Именно этим мне ASN.1 и симпатичен. Но это не принципиально, ес-но, на сегодня есть куча альтернатив.
_>Какие есть альтернативы?
Их много.
Подойдёт любой с текстовым описанием.
_>Мы начали с protobuf. Это было лет десять назад, все могло измениться. Но тогда генерируемый код был ужасен. Система типов — бедновата, даже map/dict не было.
Вот чтобы так не вляпываться, для любой технологии сначала идёт период evaluation.
Причем, желательно одновременно оценивать минимум 3 технологии.
_>На одном проекте промучались, другой начали с создания своего IDL. Реализация прототипа на Nemerle заняла две недели. Человекогоды разработки? Видимо ты перепутал с годами использования. Да, IDL развивался, но благодаря использованию Nemerle (а потом Nitra) — с минимальными трудозатратами. Правильные инструменты всегда решают.
В вашем случае решили не инструменты, а случайность.
Потому что удобных инструментов для разработки своих языков полно.
Скажи честно — сколько времени ты потратил на эксперименты с ANTLR?
Даже совершенно неопытный в деле разработки языков разработчик может за пару дней на ANTLR разработать свой язык описания сетевых сообщений.
А уж опытному (всего второй такой язык в репертуаре) — это дело единиц часов.
V>>Самая главная у тебя проблема — это много недоговариваний, преувеличений и откровенного вранья в итоге.
_>А у тебя — это хамство. Я открыт критике, но ты уж слишком много на себя берешь. Увольнения, обманутые инвесторы, вранье — ну не на базаре же.
Да, да. Проходили.
Сначала малость увлекаемся, а потом строим из себя невинную овечку...
Вот это моё сообщение было абсолютно нейтральным, т.е. сугубо техническим:
http://www.rsdn.org/forum/philosophy/6706569.1
Почитай, что и в каком виде ты там наотвечал.
Тебе был предложен тон делового обсуждения.
Ты в ответ предложил цирк.
Оууукееей. :-
Re[8]: Опциональные типы
Здравствуйте, meadow_meal, Вы писали:
_>По поводу вложенного Optional мне добавить нечего.
Тебе ответить нечего, вестимо, потому что в 3-х соснах заплутал.
Рядом коллега D. Mon на пальцах абсолютно правильно объяснил, что такое Optional/Nullable.
Это когда берется всё множество значений некоего типа и к нему добавляется еще одно СПЕЦИАЛЬНОЕ значение (некоего типа, представленного единственным значением), образуя тем самым новый тип — алгебраическую сумму исходных типов.
Прямо отсюда должно стать понятным, что если под это СПЕЦИАЛЬНОЕ значение можно выделить некое значение из исходного диапазона, то надобность складывать типы резко отпадает. Трюк стар как мир, а поди ж ты.
_>По поводу бинарной сериализации. Я не понимаю, зачем ты в разговоре постоянно скачешь с системы типов IDL на бинарную сериализацию и обратно.
Потому что IDL не предназначена для эффективной сериализации by design, вестимо.
Собсно, поэтому появился ASN.1
А еще потому, что IDL описывает синхронные вызовы, где асинхронность лишь эмулируется через возвращаемый void.
Кароч. ЗАставляешь толкать те банальности, что вот уже десяток с лишним лет как самый последний разработчик сетевых приблуд осознал, что в сети рулит просто асинхронный обмен сообщениями, т.е. встречные трафики двух ендпоинтов можно рассматривать как независимые/несинхронизированные.
Именно поэтому в ASN.1 описываются сообщения (последовательности примитивных и составных типов данных), но не интерфейсы объектов.
_>Они связаны конечно, но далеко не так прямо, как ты это хочешь представить.
Рассуждения человека, далекого от предметной области.
Это в ASN.1 прямо стандартом вводится абстрагирование самого описания данных от способов (профилей) их кодирования. На сегодня есть 4 популярных профиля кодирования.
А вот в IDL, например, в CORBA-IDL или COM-IDL бинарная сериализация прибита гвоздями ко всему. И абсолютно никакие оптимизации недопустимы, потому что есть однозначный маппинг описания на содержимое потока.
_>Битовое кодирование опциональных полей — это всего лишь деталь реализации, оптимизация, и никакого отношения к исходному вопросу не имеет.
В IDL нет битового описания опциональных полей. Если описывать union, то минимальный дискриминатор будет 1 байт. А если взять хотя бы типизированный enum в кач-ве дискриминатора (это удобно и разумно), то это будет 2 байта. Вот такие дела.
_>Прежде всего, в 2017 году странно считать, что разработка DSL и IDL вообще это rocket science.
DSL — нет, ведь они бывают разные по сложности.
Например у меня как-то ушло ровно два часа на несложный язык.
(понятно, что не первый в репертуаре + визуальный инструмент отладки грамматики + кодогенератор, но это просто показатель несложности такой работы в 2017-м)
А вот IDL — да, это рокет саенс.
Т.е., ты вводишь всех в заблуждение. По какой причине? — ХЗ.
Может плохо понимаешь, что есть IDL, но тебе нравится аббревиатура...
А может понимаешь, но хочется, чтобы звучало громче (именно это я имел ввиду, говоря, что ты врёшь).
_>Зачем нужен IDL?
IDL — это инфраструктура:
(a) для сериализации/десериализации посылки сообщений объектам;
(b) организация принципов identity объектов, прозрачной для любого языка, на который происходит маппинг.
Последнее означает, что можно делать вызовы методов объектов, независимо от их расположения. Программисту не обязательно знать, где находится объект: в текущем аппартменте текущего процесса, в другом аппартменте, в другом процессе или на другой машине.
Ты уже понял, к чему я клоню? Последнее означает, что никакой ClanID не нужен.
В системе IDL можно просто присвоить ссылку на новый клан или null, если игрок вышел из клана.
Т.е. можно писать прямо вот так на серваке (на языке программирования сервака):
И ву-а-ля. Всё будет прекрасно работать само на нормальном транспорте. И передастся на клиента. Т.е. такой код мог выполнятся на, скажем C#-серваке, а в реальности null будет присвоен объекту на C++-клиенте. Вот что такое IDL.
Т.е., твоё ClaID лично мне намекает, что никакого (b) у вас там нет и в помине, а есть лишь некое (a).
Так шта, теперь, с этими новыми знаниями, ты можешь вернуться и перечитать мой сообщение еще раз.
Тогда, может быть, тебе станет понятней, что именно я тебе писал и почему я всё это писал.
Потому что вот всем этим ответом ты показал, что не понял ни слова.
_>Ты все сводишь к протоколам коммуникации, это лишь часть айсберга. Мы занимаемся играми средних размеров (цикл разработки один-три года до релиза, и затем поддержка). Играм нужен инструментарий — дизайнерам, локализаторам, создателям контента, аналитикам, коммьюнити-менеджерам, администраторам. Писать их под каждый проект — неокупаемо. Для AAA-игр — возможно да, для нас — нет. Нужен проектно-независимый инструментарий. Кому-то нужен код, сгенерированный из IDL, кому-то схема, подтягиваемая на лету. Без единой модели данных, описанной в IDL, все развалится, потеряет актуальность.
Бла-бла, детсад.
ДУмаешь у других в области сетевых технологий как-то по-другому?
Сорри, но ты, блин, пишешь как вчерашний студент. Я бы дал не более 27-ми лет.
Только не пойми неправильно — быть вчерашним студентом ни в коем случае НЕ зазорно. Зазорно при этом игнорить накопленные практики, отказываться учиться и уж тем более должно быть зазорно надуваться по пустому поводу. Потому что как следствие обязательно идёт отсутствие развития — а это смерть специалиста и обман инвесторов. ))
_>Важная часть моей работы — оптимизация workflow.
Тогда ты тем более должен был тщательней провести исследования, как подобные задачи в принципе решают.
_>А ведь в этом нет ничего особенного, это всего лишь результат использования IDL.
У вас не IDL, у вас некий DSL.
_>Разработка начинается с IDL и завязана на IDL. Он должен быть удобным, и кодогенерация должна быть гибкой. ASN.1? Нет. Он хорошо подходит для описания стандартов сетевых протоколов, но это же совсем другая задача.
Потому что ты не понимаешь слова "абстракция", вестимо.
Как ты думаешь, что означают термины front-end и back-end?
В общем, если не в курсе — подсмотришь их самостоятельно.
Так вот. На front-end-е может исопльзоваться какой-нить простенький проблемно-ориентированный DSL. Его даже не зазорно делать уникальным для каждого отдельного проекта. Не с 0-ля, ес-но, а на каком-то общем DSL-ядре.
А вот для back-end-a для сетки надо брать что-то надёжное готовое.
Потому что иначе надо будет потратить заметное кол-во человекочасов для рождения альтернативы, как минимум не уступающей в кач-ве и надежности уже имеющимся разработкам.
Я предложил ASN.1 ровно по одной причине — это пример сугубо текстового описания на выходе, под которое можно выбирать профили кодирования. Именно этим мне ASN.1 и симпатичен. Но это не принципиально, ес-но, на сегодня есть куча альтернатив.
_>Какие есть альтернативы?
Их много.
Подойдёт любой с текстовым описанием.
_>Мы начали с protobuf. Это было лет десять назад, все могло измениться. Но тогда генерируемый код был ужасен. Система типов — бедновата, даже map/dict не было.
Вот чтобы так не вляпываться, для любой технологии сначала идёт период evaluation.
Причем, желательно одновременно оценивать минимум 3 технологии.
_>На одном проекте промучались, другой начали с создания своего IDL. Реализация прототипа на Nemerle заняла две недели. Человекогоды разработки? Видимо ты перепутал с годами использования. Да, IDL развивался, но благодаря использованию Nemerle (а потом Nitra) — с минимальными трудозатратами. Правильные инструменты всегда решают.
В вашем случае решили не инструменты, а случайность.
Потому что удобных инструментов для разработки своих языков полно.
Скажи честно — сколько времени ты потратил на эксперименты с ANTLR?
Даже совершенно неопытный в деле разработки языков разработчик может за пару дней на ANTLR разработать свой язык описания сетевых сообщений.
А уж опытному (всего второй такой язык в репертуаре) — это дело единиц часов.
V>>Самая главная у тебя проблема — это много недоговариваний, преувеличений и откровенного вранья в итоге.
_>А у тебя — это хамство. Я открыт критике, но ты уж слишком много на себя берешь. Увольнения, обманутые инвесторы, вранье — ну не на базаре же.
Да, да. Проходили.
Сначала малость увлекаемся, а потом строим из себя невинную овечку...
Вот это моё сообщение было абсолютно нейтральным, т.е. сугубо техническим:
http://www.rsdn.org/forum/philosophy/6706569.1
Почитай, что и в каком виде ты там наотвечал.
Тебе был предложен тон делового обсуждения.
Ты в ответ предложил цирк.
Оууукееей.
_>По поводу вложенного Optional мне добавить нечего.
Тебе ответить нечего, вестимо, потому что в 3-х соснах заплутал.
Рядом коллега D. Mon на пальцах абсолютно правильно объяснил, что такое Optional/Nullable.
Это когда берется всё множество значений некоего типа и к нему добавляется еще одно СПЕЦИАЛЬНОЕ значение (некоего типа, представленного единственным значением), образуя тем самым новый тип — алгебраическую сумму исходных типов.
Прямо отсюда должно стать понятным, что если под это СПЕЦИАЛЬНОЕ значение можно выделить некое значение из исходного диапазона, то надобность складывать типы резко отпадает. Трюк стар как мир, а поди ж ты.
_>По поводу бинарной сериализации. Я не понимаю, зачем ты в разговоре постоянно скачешь с системы типов IDL на бинарную сериализацию и обратно.
Потому что IDL не предназначена для эффективной сериализации by design, вестимо.
Собсно, поэтому появился ASN.1
А еще потому, что IDL описывает синхронные вызовы, где асинхронность лишь эмулируется через возвращаемый void.
Кароч. ЗАставляешь толкать те банальности, что вот уже десяток с лишним лет как самый последний разработчик сетевых приблуд осознал, что в сети рулит просто асинхронный обмен сообщениями, т.е. встречные трафики двух ендпоинтов можно рассматривать как независимые/несинхронизированные.
Именно поэтому в ASN.1 описываются сообщения (последовательности примитивных и составных типов данных), но не интерфейсы объектов.
_>Они связаны конечно, но далеко не так прямо, как ты это хочешь представить.
Рассуждения человека, далекого от предметной области.
Это в ASN.1 прямо стандартом вводится абстрагирование самого описания данных от способов (профилей) их кодирования. На сегодня есть 4 популярных профиля кодирования.
А вот в IDL, например, в CORBA-IDL или COM-IDL бинарная сериализация прибита гвоздями ко всему. И абсолютно никакие оптимизации недопустимы, потому что есть однозначный маппинг описания на содержимое потока.
_>Битовое кодирование опциональных полей — это всего лишь деталь реализации, оптимизация, и никакого отношения к исходному вопросу не имеет.
В IDL нет битового описания опциональных полей. Если описывать union, то минимальный дискриминатор будет 1 байт. А если взять хотя бы типизированный enum в кач-ве дискриминатора (это удобно и разумно), то это будет 2 байта. Вот такие дела.
_>Прежде всего, в 2017 году странно считать, что разработка DSL и IDL вообще это rocket science.
DSL — нет, ведь они бывают разные по сложности.
Например у меня как-то ушло ровно два часа на несложный язык.
(понятно, что не первый в репертуаре + визуальный инструмент отладки грамматики + кодогенератор, но это просто показатель несложности такой работы в 2017-м)
А вот IDL — да, это рокет саенс.
Т.е., ты вводишь всех в заблуждение. По какой причине? — ХЗ.
Может плохо понимаешь, что есть IDL, но тебе нравится аббревиатура...
А может понимаешь, но хочется, чтобы звучало громче (именно это я имел ввиду, говоря, что ты врёшь).
_>Зачем нужен IDL?
IDL — это инфраструктура:
(a) для сериализации/десериализации посылки сообщений объектам;
(b) организация принципов identity объектов, прозрачной для любого языка, на который происходит маппинг.
Последнее означает, что можно делать вызовы методов объектов, независимо от их расположения. Программисту не обязательно знать, где находится объект: в текущем аппартменте текущего процесса, в другом аппартменте, в другом процессе или на другой машине.
Ты уже понял, к чему я клоню? Последнее означает, что никакой ClanID не нужен.
В системе IDL можно просто присвоить ссылку на новый клан или null, если игрок вышел из клана.
Т.е. можно писать прямо вот так на серваке (на языке программирования сервака):
gamer.setClan(newClan);
// или
gamer.setClan(null);И ву-а-ля. Всё будет прекрасно работать само на нормальном транспорте. И передастся на клиента. Т.е. такой код мог выполнятся на, скажем C#-серваке, а в реальности null будет присвоен объекту на C++-клиенте. Вот что такое IDL.
Т.е., твоё ClaID лично мне намекает, что никакого (b) у вас там нет и в помине, а есть лишь некое (a).
Так шта, теперь, с этими новыми знаниями, ты можешь вернуться и перечитать мой сообщение еще раз.
Тогда, может быть, тебе станет понятней, что именно я тебе писал и почему я всё это писал.
Потому что вот всем этим ответом ты показал, что не понял ни слова.
_>Ты все сводишь к протоколам коммуникации, это лишь часть айсберга. Мы занимаемся играми средних размеров (цикл разработки один-три года до релиза, и затем поддержка). Играм нужен инструментарий — дизайнерам, локализаторам, создателям контента, аналитикам, коммьюнити-менеджерам, администраторам. Писать их под каждый проект — неокупаемо. Для AAA-игр — возможно да, для нас — нет. Нужен проектно-независимый инструментарий. Кому-то нужен код, сгенерированный из IDL, кому-то схема, подтягиваемая на лету. Без единой модели данных, описанной в IDL, все развалится, потеряет актуальность.
Бла-бла, детсад.
ДУмаешь у других в области сетевых технологий как-то по-другому?
Сорри, но ты, блин, пишешь как вчерашний студент. Я бы дал не более 27-ми лет.
Только не пойми неправильно — быть вчерашним студентом ни в коем случае НЕ зазорно. Зазорно при этом игнорить накопленные практики, отказываться учиться и уж тем более должно быть зазорно надуваться по пустому поводу. Потому что как следствие обязательно идёт отсутствие развития — а это смерть специалиста и обман инвесторов. ))
_>Важная часть моей работы — оптимизация workflow.
Тогда ты тем более должен был тщательней провести исследования, как подобные задачи в принципе решают.
_>А ведь в этом нет ничего особенного, это всего лишь результат использования IDL.
У вас не IDL, у вас некий DSL.
_>Разработка начинается с IDL и завязана на IDL. Он должен быть удобным, и кодогенерация должна быть гибкой. ASN.1? Нет. Он хорошо подходит для описания стандартов сетевых протоколов, но это же совсем другая задача.
Потому что ты не понимаешь слова "абстракция", вестимо.
Как ты думаешь, что означают термины front-end и back-end?
В общем, если не в курсе — подсмотришь их самостоятельно.
Так вот. На front-end-е может исопльзоваться какой-нить простенький проблемно-ориентированный DSL. Его даже не зазорно делать уникальным для каждого отдельного проекта. Не с 0-ля, ес-но, а на каком-то общем DSL-ядре.
А вот для back-end-a для сетки надо брать что-то надёжное готовое.
Потому что иначе надо будет потратить заметное кол-во человекочасов для рождения альтернативы, как минимум не уступающей в кач-ве и надежности уже имеющимся разработкам.
Я предложил ASN.1 ровно по одной причине — это пример сугубо текстового описания на выходе, под которое можно выбирать профили кодирования. Именно этим мне ASN.1 и симпатичен. Но это не принципиально, ес-но, на сегодня есть куча альтернатив.
_>Какие есть альтернативы?
Их много.
Подойдёт любой с текстовым описанием.
_>Мы начали с protobuf. Это было лет десять назад, все могло измениться. Но тогда генерируемый код был ужасен. Система типов — бедновата, даже map/dict не было.
Вот чтобы так не вляпываться, для любой технологии сначала идёт период evaluation.
Причем, желательно одновременно оценивать минимум 3 технологии.
_>На одном проекте промучались, другой начали с создания своего IDL. Реализация прототипа на Nemerle заняла две недели. Человекогоды разработки? Видимо ты перепутал с годами использования. Да, IDL развивался, но благодаря использованию Nemerle (а потом Nitra) — с минимальными трудозатратами. Правильные инструменты всегда решают.
В вашем случае решили не инструменты, а случайность.
Потому что удобных инструментов для разработки своих языков полно.
Скажи честно — сколько времени ты потратил на эксперименты с ANTLR?
Даже совершенно неопытный в деле разработки языков разработчик может за пару дней на ANTLR разработать свой язык описания сетевых сообщений.
А уж опытному (всего второй такой язык в репертуаре) — это дело единиц часов.
V>>Самая главная у тебя проблема — это много недоговариваний, преувеличений и откровенного вранья в итоге.
_>А у тебя — это хамство. Я открыт критике, но ты уж слишком много на себя берешь. Увольнения, обманутые инвесторы, вранье — ну не на базаре же.
Да, да. Проходили.
Сначала малость увлекаемся, а потом строим из себя невинную овечку...
Вот это моё сообщение было абсолютно нейтральным, т.е. сугубо техническим:
http://www.rsdn.org/forum/philosophy/6706569.1
Почитай, что и в каком виде ты там наотвечал.
Тебе был предложен тон делового обсуждения.
Ты в ответ предложил цирк.
Оууукееей.