Мне кажется ECS-ность не требует линейной укладки в памяти, хотя конечно фреймворки чаще делают так чем не так. Это просто архитектурная альтернатива OOP, чтобы линейное наследование «не мешалось под ногами» и у гейм-дизайнеров была возможность перекомбинировать компоненты не ломая хрупкие иерархии наследования. Есть вполне успешные ECS фреймворки на куче (C# Entitas, если я не ошибаюсь). Хотя конечно кто-то назовет их ECS-like, а не полноценными ECS. Но это уже серая зона. ECS это скорее архитектурный паттерн, тогда как линейная укладка в памяти это деталь некоторых имплементаций.
Видел во времена Adobe Flash фреймворки ECS-ные, где такое «пересечение» компонентов называлось “aspect”. Системы там работали не с конкретными типами компонентов, а с аспектами - множествами типов компонентов. Например физика работала с сочетанием трансформа и габаритов. А рендеринг с сочетанием трансформа и меша. И там было всё оптимизировано чтобы системы получали доступ именно с спискам аспектов а не к спискам компонентов. Это позволяло легко наслаивать системы друг на друга в определенном порядке. Название фреймворка уже не найду. Но мне понравилась гибкость. Маппинг был не 1 система к 1 типу компонента, а более сложная: 1 система к 1 аспекту как коллекции N типов компонентов. Очень гибко. Мне кажется движки типа Unity внутри как-то так и работают.
А почему мы например не можем (даже если это пока технически сложно/невозможно) измерить научно именно квалиа, а не спектр света? Именно проследить весь нейронный путь, все возбуждения во всех узлах? И потом сравнить полный паттер от испускания света до окончательного его приземления где-то в нервной системе, в двух людях? И потом при их достаточно близком совпадении сказать, что именно видение цвета, именно квалия такая-же? Почему квалия считается неформализуемым понятием? Что в этой квалии такого сакрального и невоспроизводимого? «Если ходит как утка, и квакает как утка…»
Для меня лично все эти квалии - просто последний теплящийся островок оставшийся со времен божественного взгляда на мир. Надо же оставить хоть что-нибудь святое и мистическое. Скорее всего, если весь электрохимический паттерн в моем и вашем мозгу одинаковый - мы именно видим один и тот же цвет, а не просто принимаем одну и ту же длину волны. Потому что больше просто нет ничего измеримого, в чем мы можем обнаружить хоть какую-то еще разницу чтобы заявлять об уникальности опыта.
И тут выше правильно подмечено. Вероятность возникновения похожих откликов от одинакового сигналов в похожих системах очень большая. Плюс минус генетические вариации и вариации развития. Разнице просто больше неоткуда взяться.
Еще плюсом (правда я так понимаю не в вашем случае), что github.com понимает Mermaid, так что эти диаграммы рисуются в ваших README из коробки. Оч круто.
thereAreManyLetters, thereIsOneLetter etc. - конечно ужасненькие названия функций. "Там много букв". Ok, Peter, but what should I do? Звучит как предикаты/утверждения из логики первого порядка. Так должны называться булевы переменные (ну или их геттеры и вот это вот всё), а не функции. Названия функций должны быть выражением, начинающимся с глагола в повелительном наклонении. Кстати, повелительное наклонение по-английски - imperative mood, что и дало название парадигме императивного программирования. It's in the name, Peter :) Эти функции должны называться FormatMessageWithOneLetter или типа того. Нужно зашивать в название функции "повелевание" к действию.
candidate и count лучше было назвать candidateLetter и candidateLetterCount, иначе не понятно количество чего, буквы-кандидата или просто какое-то количество чего-то там.
В конце предложения ставится точка: There is one %s.
Сверху еще есть хорошее мнение, что это всё завязано на английскую грамматику, и не локализуемо. Отлично подмечено. Вообще тут вся архитектура странная, да. Локализация вшита на уровне кода. Я понимаю, что это просто учебный пример. Но такие зашивки порядка слов, чисел существительных и прочее - чревато, конечно.
Я прочитал эту книжку довольно поздно, когда в голове уже сформировались паттерны, правила и стили. Мне эта книжка сразу показалась шаляй-валяй. Дядя Боб как будто сам не верит в свои принципы. Примеры кода грязные.
PS: Скобки на той же строчки, фиии :) PS: Венгерская нотация буэээ :) СкрМрПрДрБдщCandidate. Глаза сломали ногу :)
gRPC некорректно сравнивать с REST, потому что первое - протокол и фреймфорк для него, а второе - паттерн/методология. Мы же не сравниваем что лучше, ехать на автомобиле и ехать быстро. Можно легко имплементировать REST API при помощи gRPC в абсолютно строгом смысле.
Сравнивать нужно либо RPC vs REST (две методологии), либо gRPC и (чистый) HTTP (два протокола).
RPC (методолгия), если прикинуть в терминах теории множеств, - это надмножество REST. Рисуем кружочек с RPC, и кружочек с REST полностью содержится в нем и не выпирает. В RPC можно творить что угодно (это и плюс и минус), а в REST у вас система ограничений. RPC - это любые глаголы (verbs), REST - это четыре глагола. RPC - это хоть про ресурсы, хоть про операции, REST - только про уникально-идентефицируцемые ресуры (если придерживаться строгой формулировки). RPC - это хоть с состоянием, хоть без, REST - только без состояния. RPC - это любые типа/бинарка, REST - это известные типы. RPC - это любая семантика связей между чем-угодно, REST - линки между ресурсами. То есть здесь немного неочевидно ставить слово "или" ("vs.") между ними, вы можете иметь протокол, который принадлежит и REST и RPC, хотя традиционно так никто не думает. Кстати, "запихуивание" операций и состояния в REST API забирает у нас право называться REST API, если строго. Этим вообще грешит больше половины "REST" API. Обнаружили аля /operations/start - все, это не REST. RPC - это про делать (что угодно и как угодно), REST - про хранить и изменять ресурсы в системе ограничений.
gRPC vs. HTTP, тут уже надо смотреть что именно мы сравниваем. gRPC (протокол) это и transport-agnostic, и бинарка, и в обе стороны, и стриминг. Кроме того, он умеет летать поверх HTTP (что опять же делает слово "или" неуместным, можно иметь и HTTP и gRPC одновременно). gRPC (фреймфорк) - это contract-first, код-генерация, кросс-платформенность. А HTTP - вообще не фреймворк.
На макоси окна приложения не смешаны как в винде в один линейный набор, а являются дочерними к приложению. Привычный cmd+tab прыгает по приложениям, а не окнам (потому бывает можно переключиться на приложение без окон и оказаться как бы «нигде»). А вот уже при переключении на приложение вы можете перебирать его окна. На это тоже есть отдельный хоткей, не помню какой, у меня cmd+alt+tab. Как только вы интернализуете эту разницу, навигация по окнам станет простой. Сперва решил какое приложение, потом какое из его окон. В винде как раз обратная проблема иногда бывает, хотелось бы с клавиатура иерархически ходить, но alt+tab на это плевал, все вместе смешал и вам остается только прикреплять приложения к таскбару, запоминать номера позиций и жать win+1, win+2 и т.д.
Хотел написать такой же комментарий, но увидел ваш. Сцена дейстительно, помимо (спорно) искуственных привязок света и прочих вещей к ней, по сути не отличается от префаба. В это смысле любой game object с дочерними game object-ами — это и есть сцена для них дочерних. Напрашивается вопрос — почему бы тогда не унифицировать. Вспоминается старый добрый Adobe Flash, где была концепция movieclip (эквивалент game object), library movieclip (эквивалент prefab) и scene (эквивалент scene). Но вперед был выпячен так называемый root/main movieclip (могу соврать на счет названия). То есть структура была та же, но напрямую со сценой никто не работал, в отличие от Unity, все происходило в корневом мувиклипе. Хотя и можно было параллельно корневому добавить ещзе мувиклипов в саму сцену. Но этим почти никто и никогда не пользовался, а некоторые и не знали, что такое есть. Кроме того сцена была ровно одна, нельзя было отгружать одну и подгружать другу. На этом языке разговаривали мувиклипы.
Я думаю второе предложение автора комментария, на который вы ответили, про английский язык. Про спорность того, являются ли конструкции will / shall / going to действительно будущим временем. В плане смысла конечно являются. А в плане грамматики вы говорите буквально «я желаю завтра идти в парк». Что являются грамматически настоящим временем. В английском нет именно формы самого глагола, соответствующей русскому «куплю».
Прочитал ваш комментарий с удовольствием. Спасибо. Всё структурированнее, чем у меня. Я кстати не лингвист. А что, если в ваших примерах заменить страдательное причастие на «обычное» (не вспомнил, как оно называется). То есть:
Он уйден — Он ушедший
Он куплен — Он купивший
Он продан — Он продавший
Я так понимаю, в английском V3 означает и купленного и купившего? Или есть какой-то четкий исторический факт, который говорит что V3 (past participle) — соответствует только русскому страдательному причастию?
Резонно. Зачем ворошить историю, ведь сейчас уже to have перед глазами, и уступать to be обратно не планирует. Так же согласен про то, что не стоит заморачиваться над проецированием одного зыка на другой слишком сильно.
Скорее ваш второй вариант ближе. То есть речь про вас. У вас есть факт выгуливания (вами) пса. У вас есть факт нахождения (вами) ключа. Нам не найти хорошо звучащей эквивалентной конструкции на русском, потому что ее нет. Так же не воспринимайте мои изначальные «переводы» из топового комментария слишком буквально.
Ну вот думаю из-за как раз вымирания глагола to be, и выживания глагола to have как вспомогательных, не стоит переводить I have been как «я имею себя побывавшим» а стоит так, как было в оригинале «я есть побывавший». То есть глагол подменился, но смысл остался старый.
I have jumped (было раньше I am jumped) (еng.)
Ich bin gesprungen (нем.)
Я являюсь подпрыгнувшим (рус.)
То есть тут буквальность не помогает, а помогает чуточка истории.
PS: обожаю гибкость русского языка. Даешь каждому городу быть побыванным мной!
Есть совсем радикальные экстремисты, которые считают, что времени всего два: прошедшее и настоящее. И что будущего нет именно в плане формы слова. С will оно конечно-же по факту есть.
Дельный вопрос! Тут нужно оговориться, что все мои примеры конечно не претендовали на точный перевод. Основной целью было показать что все эти тантры про «действие из прошлого, но еще не закончилось бла бла бла» — это крайне неинтуитивное объяснение, с которым не понятно что делать русскоговорящему человеку. В вашем первом примере действие все же совершаю я. То есть это что-то вроде «у меня есть выгулянность собаки». Тогда как второй пример «у меня есть выгулянная собака». То есть уже про собаку, а не меня. Криво, знаю.
Оно, дельное замечание! Я бы даже задумался, пес ли выгулянный, или я его выгулявший. Но здесь, лично для меня уже слегка размывается разница. Довольно сложно спроецировать это на современный русский точно, где мы не говорим вещи вроде «я владею выгулявшестью моего пса». Радостно видеть, что есть целые книги, где пытаются исправить это растиражированное непонимание. Спасибо!
Мне кажется ECS-ность не требует линейной укладки в памяти, хотя конечно фреймворки чаще делают так чем не так. Это просто архитектурная альтернатива OOP, чтобы линейное наследование «не мешалось под ногами» и у гейм-дизайнеров была возможность перекомбинировать компоненты не ломая хрупкие иерархии наследования. Есть вполне успешные ECS фреймворки на куче (C# Entitas, если я не ошибаюсь). Хотя конечно кто-то назовет их ECS-like, а не полноценными ECS. Но это уже серая зона. ECS это скорее архитектурный паттерн, тогда как линейная укладка в памяти это деталь некоторых имплементаций.
Видел во времена Adobe Flash фреймворки ECS-ные, где такое «пересечение» компонентов называлось “aspect”. Системы там работали не с конкретными типами компонентов, а с аспектами - множествами типов компонентов. Например физика работала с сочетанием трансформа и габаритов. А рендеринг с сочетанием трансформа и меша. И там было всё оптимизировано чтобы системы получали доступ именно с спискам аспектов а не к спискам компонентов. Это позволяло легко наслаивать системы друг на друга в определенном порядке. Название фреймворка уже не найду. Но мне понравилась гибкость. Маппинг был не 1 система к 1 типу компонента, а более сложная: 1 система к 1 аспекту как коллекции N типов компонентов. Очень гибко. Мне кажется движки типа Unity внутри как-то так и работают.
А почему мы например не можем (даже если это пока технически сложно/невозможно) измерить научно именно квалиа, а не спектр света? Именно проследить весь нейронный путь, все возбуждения во всех узлах? И потом сравнить полный паттер от испускания света до окончательного его приземления где-то в нервной системе, в двух людях? И потом при их достаточно близком совпадении сказать, что именно видение цвета, именно квалия такая-же? Почему квалия считается неформализуемым понятием? Что в этой квалии такого сакрального и невоспроизводимого? «Если ходит как утка, и квакает как утка…»
Для меня лично все эти квалии - просто последний теплящийся островок оставшийся со времен божественного взгляда на мир. Надо же оставить хоть что-нибудь святое и мистическое. Скорее всего, если весь электрохимический паттерн в моем и вашем мозгу одинаковый - мы именно видим один и тот же цвет, а не просто принимаем одну и ту же длину волны. Потому что больше просто нет ничего измеримого, в чем мы можем обнаружить хоть какую-то еще разницу чтобы заявлять об уникальности опыта.
И тут выше правильно подмечено. Вероятность возникновения похожих откликов от одинакового сигналов в похожих системах очень большая. Плюс минус генетические вариации и вариации развития. Разнице просто больше неоткуда взяться.
Еще плюсом (правда я так понимаю не в вашем случае), что github.com понимает Mermaid, так что эти диаграммы рисуются в ваших README из коробки. Оч круто.
Спасибо за статью.
thereAreManyLetters,thereIsOneLetteretc. - конечно ужасненькие названия функций. "Там много букв". Ok, Peter, but what should I do? Звучит как предикаты/утверждения из логики первого порядка. Так должны называться булевы переменные (ну или их геттеры и вот это вот всё), а не функции. Названия функций должны быть выражением, начинающимся с глагола в повелительном наклонении. Кстати, повелительное наклонение по-английски - imperative mood, что и дало название парадигме императивного программирования. It's in the name, Peter :) Эти функции должны называтьсяFormatMessageWithOneLetterили типа того. Нужно зашивать в название функции "повелевание" к действию.candidateиcountлучше было назватьcandidateLetterиcandidateLetterCount, иначе не понятно количество чего, буквы-кандидата или просто какое-то количество чего-то там.В конце предложения ставится точка:
There is one %s.Сверху еще есть хорошее мнение, что это всё завязано на английскую грамматику, и не локализуемо. Отлично подмечено. Вообще тут вся архитектура странная, да. Локализация вшита на уровне кода. Я понимаю, что это просто учебный пример. Но такие зашивки порядка слов, чисел существительных и прочее - чревато, конечно.
Я прочитал эту книжку довольно поздно, когда в голове уже сформировались паттерны, правила и стили. Мне эта книжка сразу показалась шаляй-валяй. Дядя Боб как будто сам не верит в свои принципы. Примеры кода грязные.
PS: Скобки на той же строчки, фиии :)
PS: Венгерская нотация буэээ :)
СкрМрПрДрБдщCandidate. Глаза сломали ногу :).
gRPC некорректно сравнивать с REST, потому что первое - протокол и фреймфорк для него, а второе - паттерн/методология. Мы же не сравниваем что лучше, ехать на автомобиле и ехать быстро. Можно легко имплементировать REST API при помощи gRPC в абсолютно строгом смысле.
Сравнивать нужно либо RPC vs REST (две методологии), либо gRPC и (чистый) HTTP (два протокола).
RPC (методолгия), если прикинуть в терминах теории множеств, - это надмножество REST. Рисуем кружочек с RPC, и кружочек с REST полностью содержится в нем и не выпирает. В RPC можно творить что угодно (это и плюс и минус), а в REST у вас система ограничений. RPC - это любые глаголы (verbs), REST - это четыре глагола. RPC - это хоть про ресурсы, хоть про операции, REST - только про уникально-идентефицируцемые ресуры (если придерживаться строгой формулировки). RPC - это хоть с состоянием, хоть без, REST - только без состояния. RPC - это любые типа/бинарка, REST - это известные типы. RPC - это любая семантика связей между чем-угодно, REST - линки между ресурсами. То есть здесь немного неочевидно ставить слово "или" ("vs.") между ними, вы можете иметь протокол, который принадлежит и REST и RPC, хотя традиционно так никто не думает. Кстати, "запихуивание" операций и состояния в REST API забирает у нас право называться REST API, если строго. Этим вообще грешит больше половины "REST" API. Обнаружили аля /operations/start - все, это не REST. RPC - это про делать (что угодно и как угодно), REST - про хранить и изменять ресурсы в системе ограничений.
gRPC vs. HTTP, тут уже надо смотреть что именно мы сравниваем. gRPC (протокол) это и transport-agnostic, и бинарка, и в обе стороны, и стриминг. Кроме того, он умеет летать поверх HTTP (что опять же делает слово "или" неуместным, можно иметь и HTTP и gRPC одновременно). gRPC (фреймфорк) - это contract-first, код-генерация, кросс-платформенность. А HTTP - вообще не фреймворк.
Я зумаю автор имел ввиду точку с запятой вместо переноса строки.
Скеджьюл (амер.) / Щеджьюл (англ.)
На макоси окна приложения не смешаны как в винде в один линейный набор, а являются дочерними к приложению. Привычный cmd+tab прыгает по приложениям, а не окнам (потому бывает можно переключиться на приложение без окон и оказаться как бы «нигде»). А вот уже при переключении на приложение вы можете перебирать его окна. На это тоже есть отдельный хоткей, не помню какой, у меня cmd+alt+tab. Как только вы интернализуете эту разницу, навигация по окнам станет простой. Сперва решил какое приложение, потом какое из его окон. В винде как раз обратная проблема иногда бывает, хотелось бы с клавиатура иерархически ходить, но alt+tab на это плевал, все вместе смешал и вам остается только прикреплять приложения к таскбару, запоминать номера позиций и жать win+1, win+2 и т.д.
Он уйден — Он ушедший
Он куплен — Он купивший
Он продан — Он продавший
Я так понимаю, в английском V3 означает и купленного и купившего? Или есть какой-то четкий исторический факт, который говорит что V3 (past participle) — соответствует только русскому страдательному причастию?
I have jumped (было раньше I am jumped) (еng.)
Ich bin gesprungen (нем.)
Я являюсь подпрыгнувшим (рус.)
То есть тут буквальность не помогает, а помогает чуточка истории.
PS: обожаю гибкость русского языка. Даешь каждому городу быть побыванным мной!
english.stackexchange.com/questions/429932/is-it-true-that-english-has-no-future-tense