Да, но фундаментально это ничего не изменит. Эти специализации станут узким местом, их начнут еще специализировать и дообучать, они станут пропорционально дороже.
Да, но фундаментально тут то, что типы данных существуют, они важны, для их преобразования используются специальные операции. Это не религиозная концепция, этому нужно учить. В Python так то тоже нельзя сложить строку с числом. Динамическая типизация же, особенно слабая, лишь скрывает это. Это и есть то, чего хочется решить.
Это так же важно и для промышленного программирования - пусть когда то js и python сделали динамическую типизацию привлекательной фичей, сейчас куча людей пытаются решить проблемы, вызванные этим решением. TS как и аннотации типов в python придуманы не просто так.
Я и согласен фундаментально, и не согласен в детялях. Я тоже считаю что /pascal отличный для обучения с фундаментальной точки зрения, но мы решаем и множество задач при обучении. Часть из них обусловлена областями применения и практической ценностью, и, к сожалению, паскаль может быть не самым лучшим выбором здесь - да, он живет, но какая это жизнь. С этой точки зрения python может быть очень хорошим выбором - богатая инфраструктура, несколько областей для задач. С точки зрения пользы для студента возможно оптимальный выбор, это C# / Java / Kotlin - ЯП общего назначения, универсальные (десктоп и сервера для всех трех, игры на Unity для c#, нативные android приложения для Java / Kotlin).
Но в целом согласен, мне паскаль и делфи очень нравились, мне кажется это одни из самых далеко прыгнувших языков из старой школы (c/c++) в сторону современного практичного мейнстрима (питон/go/c#/Java/Kotlin). С++ конечно современный тоже есть, но это нагромождение легаси и костылей - не то что нужно использовать для обучения
Типичное импортозамещение - продукт с переклееннм шильдиком (js с переведенными ключевыми словами), некачественный (js взят за основу - отличный выбор), дорогой (нет инфраструктуры, материалов, библиотеки компонентов) и в конечном итоге никому не нужный при наличии оригинала
Эта религиозная традиция работает в python и js так же, как и в других языках, просто замазана и скрыта (что приводит к значительным проблемам и обмазыванию тестами).
Концепция типов фундаментальна и, в общем то, довольно проста - разные данные хранятся по разному, арифметические операции нельзя осуществлять с почтовыми адресами.
В их рассуждениях есть много лакун. Если какие то ресурсы станут очень дешевыми (даже труд), то какие то переоценятся как дорогие. Если копия дешевая - сервис по обслуживанию становится основной услугой. Если связь дешевая - пропускные способности. Если производство дешевое - энергия и материалы и т.д.
Сейчас выглядит, что основное это человеческое внимание. Хотя заглядывая в AGI конечно никакой сценарий не безумный.
Возможно кому то подход понравится. Если планируете развивать - подумайте о штуках, которые могут улучшить привлекательность подхода - например, сохранение / загрузка из коробки (если у вас есть централизованный список сущностей и компонентов - должно быть тривиально), инструменты визуализации, возможно - инструменты визуального программирования.
Я очень ценю самостоятельных авторов и их эксперименты, новые идеи и свободные библиотеки. Но ваш подход видится мне настолько фундаметнально ошибочным сразу на стольких направлениях, что у меня даже немножко горит.
Но постараюсь описать конструктивно, все же фидбек важен.
Итак начнем.
Сначала небольшой дисклеймер. Я считаю ECS довольно элегантной и крутой идеей, но очень специализированной архитектурой. Плюсами является скорость и хранение стейта (что почти за бесплатно дает сохранения/снапшоты/повторы и работу по сути), а так же плоская структура. Минусами - сложность, большее количество кода и очень жесткие требования по организации и архитектуре для хорошего кода (ровно противоположное от того, что говорят апологеты). Из-за разделения данных и кода, вторичной системы индексирования (индексы/сущности вместо ссылок в памяти) код очень сложно читать и понимать, а так же дебажить (хотя прозрачное состояние тут плюс). Люди неоднократно говорили мне, что им так проще, но практика совместной разработки показывала, что код легко превращается в ад. 2 основных проблемы - из-за разделения операций на действия и сущности для понимания поведения какого то объекта (скажем персонажа с оружием) нужно собрать в голове в правильном порядке все сущности и операции с ними, потому что они размазаны по проекту. И аналогично, для организации иерархии объектов (а они естественны) необходимо собирать эти деревья по ссылочкам руками - юнит, в нем индекс пушки, из нее сущность пушки в ней компонент заряда, в нем индекс заряда из нее сущность заряда из нее параметры компонента с типом патрончика - как то так.
Ваш паттерн фундаментально следует логике ECS в смысле разделения данных и кода, соответственно почти все части этой критики применимы и к вашему фреймворку.
Отказ от структуры Unity ведет к довольно большому количество Boilerplate кода (создание и описание сущностей, файлы поведения + накладные расходы на описание инсталлеров и мапперов), к управлению действиями нужно привыкать, вы так же теряете серьезную часть редактора (объекты можно писать в таком стиле, чтобы их могли использовать геймдизайнеры, их можно было комбинировать с существующими и сторонними компонентами самой Unity.
Ну и производительность. Во первых, у вас каждое обращение каждого поведения достает компоненты. Даже если бакеты достаточно шустрые, там боксинг/анбоксинг с приведением. Во вторых само по себе доставание - операция более дорогая чем доступ по ссылке. Mono Behaviour все считают очень медленными, что конечно правда по сравнению с plane объектами и специализированными решениями, но совершенно не правда в целом. Обычно проблемы вызваны неуемным использованием самых разнообразных компонентов. Если вы разделяете логику и представление (а вы насильно делаете это, в этом ведь суть фреймворка), то вы, аналогично многим ECS решениям, просто заставляете разработчика задумываться о том, сколько и чего он использует. Но это не корректное сравнение - в таком случае нужно сравнивать с чистыми plane объектами (не наследниками MonoBehaviour, а обычными структурами и классами), использующими MB только как визуализацию. Я конечно свечку не держал, может у вас есть цифры, но просто по коду двух основных гирь - регистрации и доступу к компонентам, Я не вижу как этот подход может быть производительнее. Плюс использование интерфейсов может мешать компилятору резолвить типы ваших сущностей к реальным типам, у вас много приведений к object
У меня есть ощущение, что многие люди разочаровались в ООП, потому что приняли его слишком серьезно, вот и у вас - сам код фреймворка написан по всем стандартам, с разделением всего на интерфейсы, стройной иерархией. Но чудовищными partial классами, напрочь ломающими инкапсуляцию и делающие чтение фреймворка адком.
По сути, если хочется достигнуть подобного минималистичными методами, можно просто использовать анемичные объекты - делать все объекты с public полями, собирать все действия в аналоги систем (поведений, не суть) - будет ровно та простота, которую вы предлагаете. И не нужно строить костыли для производльного доступа к виртуальным полям просто чтобы игнорировать сложности классического ООП которые могут вам мешать (но которые на самом деле не требуются)
Единственное, в чем ваша абстракция могла бы помочь - это если бы вынести ее на уровень представления, дать возможность геймдизайнерам собирать объекты из свойств и поведений с визуальным редактором, но приличной производительностью. ГД безусловно будут писать треш и ересь, но будут очень рады такому инструменту. Это иллюзия, что такая организация спасает от архитектуры. Архитектура - это прежде всего связь между вашими сущностями, а не ECB. Такую же архитектуру придется продумывать, только в рамках вашей системы, без инструментов для работы с ней.
В моем представлении вы выплеснули с водой младенца - никаких преимуществ ECS, но все его недостатки со своими собственными. Я могу быть разумеется не прав, и конкретно для вас это может быть хорошим подходом. Но предостерегаю.
В вашей статье все в целом описано, но простого ответа не дано:
Сервера не унаследовали названия мейнфремов потому что сервера не являются их прямыми потомками и наследниками.
Мейнфреймы - это большие компьютеры, к которым пользователи подключаются через терминалы.
В какой то момент, когда компьютеры были большими и дорогими, это был основной способ организации вычислений. Но основное развитие получили микрокомпьютеры / персональные компьютеры, и большие сети (и сервера на них) стали строить на основе этой ветки компьютерной техники.
И хотя конкретно такое направление бизнес-компьютеров полностью не умерло, оно скорее смещалось в сторону более популярных решений, и настоящие мейнфреймы по сути слились с мощными серверами и суперкомпьютерами.
Просто это пункт №2 в правилах для путешественников во времени: 1. Нельзя убивать Гитлера 2. Нельзя посещать вечеринку Хокинга для путешественников во времени.
Да, вот только мы не знаем, спринт это или марафон, кроме того проблема продуктивного использования времени - организационная. Не важно, как долго ты бежишь, если бежишь не в ту сторону, не важно как долго ты несешь эстафету, если ее кто-то не подхватит и не понесет дальше.
Кароч это выглядит как попытка сэкономить на сотрудниках. Причем повышенные зарплаты обычно не кейс, иначе можно было бы просто нанять и сорганизовать двоих или троих сотрудников и обеспечить хоть 24-х часовой цикл разработки.
Присоединяюсь к вопросу, как минимум внутренние имена должны стать нечитаемыми, только часть биндингов можно достать из метаданных (сериализация к примеру)
А еще есть исходники телеграма, часть модулей можно сравнить с ними
Мой комментарий именно про это - что нужно доверие ко всему пайплайну. И в конечном итоге это не защитит от фотографии экрана/распечатанной фотки фейка.
Все так, но нужно доверие как к началу (что камера действительно подписывает только сырые изображения с сенсора и обмануть ее нельзя) так и ко всей цепочке - например, будет ли это лишь этот производитель, или могут быть другие? Кто будет их удостоверять?
Ну и в конечном итоге можно просто сфоткать экран/фотографию с фейком, если они имеют достаточное разрешение
Это лишь докажет, что этот источник сделал кадр. Как это поможет с доверием к самому источнику, непонятно. Типа "вот сертификат, что Я - это Я", а кто таков - да хрен с горы.
Да, но фундаментально это ничего не изменит. Эти специализации станут узким местом, их начнут еще специализировать и дообучать, они станут пропорционально дороже.
Да, но фундаментально тут то, что типы данных существуют, они важны, для их преобразования используются специальные операции. Это не религиозная концепция, этому нужно учить. В Python так то тоже нельзя сложить строку с числом.
Динамическая типизация же, особенно слабая, лишь скрывает это.
Это и есть то, чего хочется решить.
Это так же важно и для промышленного программирования - пусть когда то js и python сделали динамическую типизацию привлекательной фичей, сейчас куча людей пытаются решить проблемы, вызванные этим решением. TS как и аннотации типов в python придуманы не просто так.
Я и согласен фундаментально, и не согласен в детялях.
Я тоже считаю что /pascal отличный для обучения с фундаментальной точки зрения, но мы решаем и множество задач при обучении. Часть из них обусловлена областями применения и практической ценностью, и, к сожалению, паскаль может быть не самым лучшим выбором здесь - да, он живет, но какая это жизнь.
С этой точки зрения python может быть очень хорошим выбором - богатая инфраструктура, несколько областей для задач.
С точки зрения пользы для студента возможно оптимальный выбор, это C# / Java / Kotlin - ЯП общего назначения, универсальные (десктоп и сервера для всех трех, игры на Unity для c#, нативные android приложения для Java / Kotlin).
Но в целом согласен, мне паскаль и делфи очень нравились, мне кажется это одни из самых далеко прыгнувших языков из старой школы (c/c++) в сторону современного практичного мейнстрима (питон/go/c#/Java/Kotlin). С++ конечно современный тоже есть, но это нагромождение легаси и костылей - не то что нужно использовать для обучения
Типичное импортозамещение - продукт с переклееннм шильдиком (js с переведенными ключевыми словами), некачественный (js взят за основу - отличный выбор), дорогой (нет инфраструктуры, материалов, библиотеки компонентов) и в конечном итоге никому не нужный при наличии оригинала
Эта религиозная традиция работает в python и js так же, как и в других языках, просто замазана и скрыта (что приводит к значительным проблемам и обмазыванию тестами).
Концепция типов фундаментальна и, в общем то, довольно проста - разные данные хранятся по разному, арифметические операции нельзя осуществлять с почтовыми адресами.
В их рассуждениях есть много лакун.
Если какие то ресурсы станут очень дешевыми (даже труд), то какие то переоценятся как дорогие.
Если копия дешевая - сервис по обслуживанию становится основной услугой. Если связь дешевая - пропускные способности. Если производство дешевое - энергия и материалы и т.д.
Сейчас выглядит, что основное это человеческое внимание.
Хотя заглядывая в AGI конечно никакой сценарий не безумный.
Возможно кому то подход понравится. Если планируете развивать - подумайте о штуках, которые могут улучшить привлекательность подхода - например, сохранение / загрузка из коробки (если у вас есть централизованный список сущностей и компонентов - должно быть тривиально), инструменты визуализации, возможно - инструменты визуального программирования.
Ох...
Я очень ценю самостоятельных авторов и их эксперименты, новые идеи и свободные библиотеки.
Но ваш подход видится мне настолько фундаметнально ошибочным сразу на стольких направлениях, что у меня даже немножко горит.
Но постараюсь описать конструктивно, все же фидбек важен.
Итак начнем.
Сначала небольшой дисклеймер. Я считаю ECS довольно элегантной и крутой идеей, но очень специализированной архитектурой. Плюсами является скорость и хранение стейта (что почти за бесплатно дает сохранения/снапшоты/повторы и работу по сути), а так же плоская структура. Минусами - сложность, большее количество кода и очень жесткие требования по организации и архитектуре для хорошего кода (ровно противоположное от того, что говорят апологеты). Из-за разделения данных и кода, вторичной системы индексирования (индексы/сущности вместо ссылок в памяти) код очень сложно читать и понимать, а так же дебажить (хотя прозрачное состояние тут плюс). Люди неоднократно говорили мне, что им так проще, но практика совместной разработки показывала, что код легко превращается в ад. 2 основных проблемы - из-за разделения операций на действия и сущности для понимания поведения какого то объекта (скажем персонажа с оружием) нужно собрать в голове в правильном порядке все сущности и операции с ними, потому что они размазаны по проекту. И аналогично, для организации иерархии объектов (а они естественны) необходимо собирать эти деревья по ссылочкам руками - юнит, в нем индекс пушки, из нее сущность пушки в ней компонент заряда, в нем индекс заряда из нее сущность заряда из нее параметры компонента с типом патрончика - как то так.
Ваш паттерн фундаментально следует логике ECS в смысле разделения данных и кода, соответственно почти все части этой критики применимы и к вашему фреймворку.
Отказ от структуры Unity ведет к довольно большому количество Boilerplate кода (создание и описание сущностей, файлы поведения + накладные расходы на описание инсталлеров и мапперов), к управлению действиями нужно привыкать, вы так же теряете серьезную часть редактора (объекты можно писать в таком стиле, чтобы их могли использовать геймдизайнеры, их можно было комбинировать с существующими и сторонними компонентами самой Unity.
Ну и производительность.
Во первых, у вас каждое обращение каждого поведения достает компоненты. Даже если бакеты достаточно шустрые, там боксинг/анбоксинг с приведением. Во вторых само по себе доставание - операция более дорогая чем доступ по ссылке.
Mono Behaviour все считают очень медленными, что конечно правда по сравнению с plane объектами и специализированными решениями, но совершенно не правда в целом. Обычно проблемы вызваны неуемным использованием самых разнообразных компонентов.
Если вы разделяете логику и представление (а вы насильно делаете это, в этом ведь суть фреймворка), то вы, аналогично многим ECS решениям, просто заставляете разработчика задумываться о том, сколько и чего он использует. Но это не корректное сравнение - в таком случае нужно сравнивать с чистыми plane объектами (не наследниками MonoBehaviour, а обычными структурами и классами), использующими MB только как визуализацию.
Я конечно свечку не держал, может у вас есть цифры, но просто по коду двух основных гирь - регистрации и доступу к компонентам, Я не вижу как этот подход может быть производительнее. Плюс использование интерфейсов может мешать компилятору резолвить типы ваших сущностей к реальным типам, у вас много приведений к object
У меня есть ощущение, что многие люди разочаровались в ООП, потому что приняли его слишком серьезно, вот и у вас - сам код фреймворка написан по всем стандартам, с разделением всего на интерфейсы, стройной иерархией. Но чудовищными partial классами, напрочь ломающими инкапсуляцию и делающие чтение фреймворка адком.
По сути, если хочется достигнуть подобного минималистичными методами, можно просто использовать анемичные объекты - делать все объекты с public полями, собирать все действия в аналоги систем (поведений, не суть) - будет ровно та простота, которую вы предлагаете. И не нужно строить костыли для производльного доступа к виртуальным полям просто чтобы игнорировать сложности классического ООП которые могут вам мешать (но которые на самом деле не требуются)
Единственное, в чем ваша абстракция могла бы помочь - это если бы вынести ее на уровень представления, дать возможность геймдизайнерам собирать объекты из свойств и поведений с визуальным редактором, но приличной производительностью.
ГД безусловно будут писать треш и ересь, но будут очень рады такому инструменту.
Это иллюзия, что такая организация спасает от архитектуры. Архитектура - это прежде всего связь между вашими сущностями, а не ECB. Такую же архитектуру придется продумывать, только в рамках вашей системы, без инструментов для работы с ней.
В моем представлении вы выплеснули с водой младенца - никаких преимуществ ECS, но все его недостатки со своими собственными.
Я могу быть разумеется не прав, и конкретно для вас это может быть хорошим подходом. Но предостерегаю.
В вашей статье все в целом описано, но простого ответа не дано:
Сервера не унаследовали названия мейнфремов потому что сервера не являются их прямыми потомками и наследниками.
Мейнфреймы - это большие компьютеры, к которым пользователи подключаются через терминалы.
В какой то момент, когда компьютеры были большими и дорогими, это был основной способ организации вычислений.
Но основное развитие получили микрокомпьютеры / персональные компьютеры, и большие сети (и сервера на них) стали строить на основе этой ветки компьютерной техники.
И хотя конкретно такое направление бизнес-компьютеров полностью не умерло, оно скорее смещалось в сторону более популярных решений, и настоящие мейнфреймы по сути слились с мощными серверами и суперкомпьютерами.
Просто это пункт №2 в правилах для путешественников во времени:
1. Нельзя убивать Гитлера
2. Нельзя посещать вечеринку Хокинга для путешественников во времени.
Да, вот только мы не знаем, спринт это или марафон, кроме того проблема продуктивного использования времени - организационная.
Не важно, как долго ты бежишь, если бежишь не в ту сторону, не важно как долго ты несешь эстафету, если ее кто-то не подхватит и не понесет дальше.
Кароч это выглядит как попытка сэкономить на сотрудниках. Причем повышенные зарплаты обычно не кейс, иначе можно было бы просто нанять и сорганизовать двоих или троих сотрудников и обеспечить хоть 24-х часовой цикл разработки.
Ну вот такой вот у нас коммунизм, особенный - миллиардеры из КПК подтвердят.
Ну что за желтушная ерунда, не скопировали они его за 2 дня же.
Просто очень похожая разработка, либо оба концепта базируются на чем то третьем
Сколько граждан РФ уже репрессировали?
Присоединяюсь к вопросу, как минимум внутренние имена должны стать нечитаемыми, только часть биндингов можно достать из метаданных (сериализация к примеру)
А еще есть исходники телеграма, часть модулей можно сравнить с ними
Ну это и есть разбор - не только сервера телеграма
Мой комментарий именно про это - что нужно доверие ко всему пайплайну.
И в конечном итоге это не защитит от фотографии экрана/распечатанной фотки фейка.
Все так, но нужно доверие как к началу (что камера действительно подписывает только сырые изображения с сенсора и обмануть ее нельзя) так и ко всей цепочке - например, будет ли это лишь этот производитель, или могут быть другие? Кто будет их удостоверять?
Ну и в конечном итоге можно просто сфоткать экран/фотографию с фейком, если они имеют достаточное разрешение
Это лишь докажет, что этот источник сделал кадр.
Как это поможет с доверием к самому источнику, непонятно.
Типа "вот сертификат, что Я - это Я", а кто таков - да хрен с горы.
В данном случае важно на что идут доходы.