А почему автономия — лучший критерий чем качество? Условно: зачем мне возиться с так сеье сытной гидропоникой, когда курьер за час привезет сытную, вкусную, так еще и по калориям посчитанную еду?
Тут все не так плохо, за последние пару лет:
1) Переродились rougelike (hollow night, issac, dead cells, etc.)
2) Стали понятны широкой публике игры про оптимизацию
— Симуляторы поселений вроде rimworld и prison architect (происходят от имеющий бесконечный порог входа dwarf fortress)
— Появляется множество вариаций на тему factorio (которая кстати #2 в топе рейтинга в стиме)
3) Battle royale (по сути событие размером с появление MOBA в ранних 2010x)
4) Космопесочницы (space engineers, no man's sky, astroneer etc.)
И это не считая очень интересные единичные игры вроде superhot или into the breach
Если смотреть на AAA, конечно, будет казаться, что все застряло, но это скорее вызывано тем, что в AAA сильное отклонение от проверенных формул просто несет с собой слишком большие денежные риски
Как говорили выше: если вы найдете ментора который давал задание и спросите напрямую, фидбек вы скорее всего получите.
Кроме структуры и расширяемости решения в целом(писали выше), ваш английский заментно хромает, а это тоже сказывается на качестве кода / быстром поике информации(вы скорее всего плохо "сканируете" условые issue на предмет того, что вас интересует). Это тоже могло повлиять на выбор стажера.
Заодно зову k12th
Спорный момент вытягивания gamedev паттернов в том, что там часто разменивают DX на производиьельность. С точки зрения дизайна api хуков в реакте очень удачное решение. Код группируется и выносится исходя из решаемых задач, а не вокруг методов жизненного цикла(и не приходится иметь десятки таких методов как юнити), при этом все вызовы явные и легко делятся данными. (причем обменном данными тоже явно управляет подключающий компонент, а не конвенции)
Из минусов сответственно производительность и запрет вызова хука в условных конструкциях. (что впрочем вызвало у нас проблемы лишь однажды за несколько месяцев использования и сразу решилось разделением компонента на 2)
В свое время взял PS4 pro ради персоны 5, честно сказать подобрать пк аналог у меня с все еще не получилось. Ну и некоторые игры(скажем overwatch), хотя выходят на пк и я могу полюбоваться на тенюшки правильной формы в сущности явно задизайнены под консольный стиль игры где все больше двигаются и меньше целятся, а на пк являются безумно унылыми. А еще клавомышь в экшонах это спортивный снаряд, а не инструмент развлечения. И микрофоны при консолях обычно есть только у прятных людей, а не реки говна в войсе и обычном чате. Вопросов нет, VR, CRPG и стратегии лучше на пк. Все хорошее инди либо выйдет на консоли, либо все равно отлично бегает на рабочем ноуте. И да, не думать про компоненты/настройки — отличная штука. Но вот плохо с консолями то, что на них можно запускать всякое, а вот создавать — увы.
Это все к тому, что пк гейминг дело хорошее, но нишевое и обращать в него людей — дело гиблое.
Хмм, ну вот тут переосмысленная реактивность еще хитрее прошлых подходов.
В условном mobx \ vue не надо ждать requestAnimationFrame чтобы computed пересчитался
(понятно, что я могу вооружиться геттерФункцией + memoize one + ее вызовом в $: ($: чтобы не тащить логику в шаблон). И добиться такого же поведения в svelte, но это уже весьма неудобно.
Про цикл наброс был на то, что раз уж у вас умный компилятор
Зачем делать for(i...) { ++i; $$invalidate('i', i) }
Когда можно
for(i...) ++i;
$$invalidate('i', i)
Хотя если invalidate дешевый я тоже не понимаю, отчего ecmaeology так всполошился
Туториал про таблички начинается с бага (надо снять фокус с a1 чтобы значения появилось, потом начинает норм работать)
Контрибьторы идут до хоть чего-то про инструмент, сайт — галерея компонентов без слова про фреймворк (для сравнения react начинается с описания и потом сразу примеры основных концептов и interop с внешними либами)
И в этом туториале почти сразу `<= Head -` без объяснения что за волшебный минус.
Поиграться с кодом на промежуточных стадиях нельзя. Т.е. та же проблема: доступность страдает.
> click?event <=> decrement?event null
Ну вот как-то нет
Почему я вдруг в 2 стороны связался с кликом? Я их только потреблять вроде хочу. Но как я понял тут 2 стороны это что-то вроде «я компоненту listener, а он мне в него ивенты.»
Только поигравшись в компайлере можно понять, что? влияет на event, а не на click, кстати почему так?
Что null тут делает вообще, в другом месте это вроде стандартное значение?
> а так, чтобы задействовать уже существующий ассоциации
Так определенно стало понятнее, но `=>` все еще сложно понять.
`@` тоже едва очевидный, но можно понять после объяснения
И все же, почему не парные скобки, а / * для массивов и объектов?
> интерпретация действий пользователя
Речь про ивент листенеры, они есть, да и вообще в view.tree стандартные значения пишутся (судя по `value 0`)
Вступление
Я говорил о том, почему $mol, на мой взгляд, в текущей своей форме распространенным стать не может, т.к. у него очень низкая доступность. А не про то, где его расположить на глобальной шкале фреймворков и DSL.
Сначала отвечу фидбеком, потом попробую написать полезные вещи про конкретные аспекты view tree.
Примеры ниже будут от моего лица, но, кажется, они справедливы для большинства frontend разработчиков.
Если новую концепцию можно понять сходу, то не такая уж она и новая.
Да. Только новизна сама по себе — не то чтобы положительное свойство (с прикладной точки зрения), это конечно очень весело, но едва продуктивно.
ему не нужны линтеры
Ок, но форматтеры все еще нужны т.к. договариваться в пулл реквестах и постоянно думать про то, как оформлен код, неудобно. Тут все еще можно написать с маленькой буквы то, что принято писать с большой и поставить 2 пробела, где принято 1.
Любой синтаксис не понятен, пока не ознакомишься с документацией.
Тут есть 2 нюанса.
"ментальное расстояние" между 2 языками(синтаксисами), мне как-то не понадобилось читать доки, когда я первый раз увидел, скажем, jsx. Потому что он выглядит как html, где можно написать { и писать js до следующей }. Потому что писать js html я уже умею, а фигурные скобочки для переключения синтаксиса — конвенция в куче шаблонизаторов, языков, да и в самом js Right? ${true ? 'yes' : 'no'}.
Аналогичная вещи произошла с elm, если показать случайному фронту https://ellie-app.com/37gVmD7Tm9Ma1, он даже не зная elm по цвету слов и буквам в них опишет, что там происходит. Т.е. если птичий синтаксис оперирует такими же понятиями (функции, аргументы, массивы, объекты, поля, переменные) и одинаково обозначает структуры данных, его сильно легче воспринять, чем принципиально альтернативный подход. (понял большую сразу верно для кучи всего, elm, sass, toml, kotlin, C#, go, vue, т.д). Для $mol и view.tree верно скорее понял примерно ничего, почитал и стало ненамного лучше.
Нагрузка на память. Это главная беда решений, которые начинаются с прочтения документации. Человек не сразу запоминает связь символов и семантики, значит если код не подсказывает свой смысл сам, придется регулярно проверять, что он делает. Это долго и удручающе, никто не хочет этим заниматься. В этом главная проблема операторов, которыми пестрит view tree. Они не намекают на то, в чем их смысл. Слова это делают. Операторы которые человек уже знает. Например: [] для массивов и {} для объектов это делают, / и * — нет, более того, у многих они зарезервированы под деление и умножение (или wildcard), и приклеивать им дополнительные смыслы энергозатратно. Причем в этом же проекте их надо будет мыслить по-старом, ведь не все можно на view tree написать. Не просто так люди со скрипом пишут (если вообще справляются) regex из головы.
А что такое хороший дизайн в вашем представлении?
В данном случае говорим про дизайн языков, я бы выделил 6 критериев (которые все в сущности ведут к одному: инструментом просто решать задачи сразу)
Простота восприятия (выразительность) — описание решения задачи на данном языке максимально понятно (не важно насколько оно короткое)
Первичная доступность — количество усилий, которые целевой пользователь языка должен приложить, чтобы начать использовать его для своих задач
Запоминаемость — простота восприятия и создание кода на языке без использования дополнительных источников (т.к. это быстрее, приятнее и позволяет не терять контекст задачи которую пользователь пытается решить с помощью языка)
Безусловность (ортогональность) — насколько сущности в языке (такие как, например, значение, выражение, указатель, тип, функция и т.д.) взаимозаменяемы.
Покрытие области — могу ли я комфортно и эффективно решить все свои задачи используя только этот язык? Нет. Какую их часть я могу так решить?
Инструментарий совместной работы — Насколько легко использовать чужой код? Насколько легко параллельно делать несколько задач? Несколькими людьми? Есть ли инструменты, упрощающие чтение? (подсветка синтаксиса, go to definition и ему подобные, автоформаттинг (чтобы повысить привычность чужого кода, если язык позволяет разные формы записи).
Менее личное и (возможно) более полезное
Не факт что я скажу тут что-то новое, но сейчас создается впечатление, что эти пункты игнорируются.
На ваш язык мигрируют js разработчики. Они привыкли, что \n что-то значит, отступы — нет. Они привыкли что структуры данных открываются и закрываются. Они привыкли к модели родитель\ребенок, а не sub и т.д.
Операторы не намекают на свой смысл, значит, язык, в котором их много, требует больше ментального ресурса, для восприятия. (чем словесный)
Разрыв компонентов — шаблон не зависит от логики, структура от стилей и т.д. звучит очень красиво, но это ложь. Условия показа, интерпретация действий пользователя, повторения — инъекция логики в шаблон. Ну а будь в вебе все настолько волшебно, что структура независима от стилей div (структурное ничто) был бы не нужен, а он, наверное самый популярный тег сегодня. React + css-in-js \ Vue SFC не просто так набрали популярность. (хотя я так и не понял, $mol советует компонентный подход или что)
Подход "все говно, $mol \ view tree — пушка" вызывает защитную реакцию и желание искать изъяны, а не понимать чем хорошо данное предложение.
Отсутствие туториалов мешает пониманию. Большинству при первом знакомстве интересно "берем A B C и получаем вот такую пушку", очень желательно редактируемо и прямо в браузере. (есть примеры, но их надо смотреть отдельно, и они без вставок о философии, сущностях и целях инструмента)
$mol хвалится стандартной библиотекой компонентов, при этом нет не 1 примера вида: берем $mol_button и добавляем ей :active \ убираем border-radius с выделенных дат в календаре и т.д. Т.к. дизайн библиотеки компонентов $mol не в том, состоянии, чтобы брать ее дизайн как есть, а как его поправить или переопределить — непонятно. Ну а большим компаниям чужой стиль тем более не нужен, так что для них $mol — в лучшем случае "низкоурованеый фреймворк".
Итого
Скорее всего в $mol есть куча хороших идей и решений, но за ними надо непонятно где и куда копать, а его подача мотивации не прибавляет.
$my_heroes $mol_view
sub /
<= Title $mol_view
sub /
<= title \
<= Title_sub $mol_view
sub /
<= title_sub @ \My Heroes
<= Rows $mol_list
rows <= rows /
Сходу не могут понять ни люди, ни анализаторы кода для js (фичи ide rip, литеры rip).
Повсюду какие-то слеши в разные стороны, спецсимволы, чтобы указывать на типы.
$my_heroes $mol_view
sub /
<= Title $mol_view
Стрелочка влево означает получение значения свойства, а после неё идёт собственно объявление этого свойства указанием его имени и значения через пробел.
Это получить свойство Title из $mol_view или объявление его на $mol_heros или что вообще?
UPD: Даже посмотрев во что это компилится, ощущения что это хороший дизайн не стало.
А почему автономия — лучший критерий чем качество? Условно: зачем мне возиться с так сеье сытной гидропоникой, когда курьер за час привезет сытную, вкусную, так еще и по калориям посчитанную еду?
Т.е. Подключил один кабель и вуаля, теперь моник — твой личный комп. (вроде у монторов начиная с 2019 наличие такого порта уже не редкость)
1) Так зачем передавать функцию?
2) Как обеспечить обязательность слотов на уровне typescript?
Единственный вопрос насколько метод в этой статье отличается/способен конкурировать с Nvidia DLSS2, который уже в продакшене.
А можете рассказать как вы строите процессы при разработке таких продуктов? А заодно пояснить как вы разделяте их на типовые и сложные?
Ну вот в том же яндексе акции по результатам пологодового ревью — значимая часть дохода
На мой вкус штука сейчас безумно кривая, но мб в ней можно найти полезных концептов
1) Переродились rougelike (hollow night, issac, dead cells, etc.)
2) Стали понятны широкой публике игры про оптимизацию
— Симуляторы поселений вроде rimworld и prison architect (происходят от имеющий бесконечный порог входа dwarf fortress)
— Появляется множество вариаций на тему factorio (которая кстати #2 в топе рейтинга в стиме)
3) Battle royale (по сути событие размером с появление MOBA в ранних 2010x)
4) Космопесочницы (space engineers, no man's sky, astroneer etc.)
И это не считая очень интересные единичные игры вроде superhot или into the breach
Если смотреть на AAA, конечно, будет казаться, что все застряло, но это скорее вызывано тем, что в AAA сильное отклонение от проверенных формул просто несет с собой слишком большие денежные риски
Как говорили выше: если вы найдете ментора который давал задание и спросите напрямую, фидбек вы скорее всего получите.
Кроме структуры и расширяемости решения в целом(писали выше), ваш английский заментно хромает, а это тоже сказывается на качестве кода / быстром поике информации(вы скорее всего плохо "сканируете" условые issue на предмет того, что вас интересует). Это тоже могло повлиять на выбор стажера.
Заодно зову k12th
Спорный момент вытягивания gamedev паттернов в том, что там часто разменивают DX на производиьельность. С точки зрения дизайна api хуков в реакте очень удачное решение. Код группируется и выносится исходя из решаемых задач, а не вокруг методов жизненного цикла(и не приходится иметь десятки таких методов как юнити), при этом все вызовы явные и легко делятся данными. (причем обменном данными тоже явно управляет подключающий компонент, а не конвенции)
Из минусов сответственно производительность и запрет вызова хука в условных конструкциях. (что впрочем вызвало у нас проблемы лишь однажды за несколько месяцев использования и сразу решилось разделением компонента на 2)
В свое время взял PS4 pro ради персоны 5, честно сказать подобрать пк аналог у меня с все еще не получилось. Ну и некоторые игры(скажем overwatch), хотя выходят на пк и я могу полюбоваться на тенюшки правильной формы в сущности явно задизайнены под консольный стиль игры где все больше двигаются и меньше целятся, а на пк являются безумно унылыми. А еще клавомышь в экшонах это спортивный снаряд, а не инструмент развлечения. И микрофоны при консолях обычно есть только у прятных людей, а не реки говна в войсе и обычном чате. Вопросов нет, VR, CRPG и стратегии лучше на пк. Все хорошее инди либо выйдет на консоли, либо все равно отлично бегает на рабочем ноуте. И да, не думать про компоненты/настройки — отличная штука. Но вот плохо с консолями то, что на них можно запускать всякое, а вот создавать — увы.
Это все к тому, что пк гейминг дело хорошее, но нишевое и обращать в него людей — дело гиблое.
Хмм, ну в СПбГУ читают теорию автоматов и рв используя запись как в тесте.
В условном mobx \ vue не надо ждать requestAnimationFrame чтобы computed пересчитался
(понятно, что я могу вооружиться геттерФункцией + memoize one + ее вызовом в $: ($: чтобы не тащить логику в шаблон). И добиться такого же поведения в svelte, но это уже весьма неудобно.
svelte.dev/repl?version=3.1.0&gist=38667c3b7f224c1187e0dbb6238bee52
PaulMaly почини мой gist, если я еще не понял как объяснить мысль svelte.
Предположение было такое, что sheep всегда держит актуальное состояние i.
Зачем делать for(i...) { ++i; $$invalidate('i', i) }
Когда можно
for(i...) ++i;
$$invalidate('i', i)
Хотя если invalidate дешевый я тоже не понимаю, отчего ecmaeology так всполошился
Туториал про таблички начинается с бага (надо снять фокус с a1 чтобы значения появилось, потом начинает норм работать)
Контрибьторы идут до хоть чего-то про инструмент, сайт — галерея компонентов без слова про фреймворк (для сравнения react начинается с описания и потом сразу примеры основных концептов и interop с внешними либами)
И в этом туториале почти сразу `<= Head -` без объяснения что за волшебный минус.
Поиграться с кодом на промежуточных стадиях нельзя. Т.е. та же проблема: доступность страдает.
> click?event <=> decrement?event null
Ну вот как-то нет
Почему я вдруг в 2 стороны связался с кликом? Я их только потреблять вроде хочу. Но как я понял тут 2 стороны это что-то вроде «я компоненту listener, а он мне в него ивенты.»
Только поигравшись в компайлере можно понять, что? влияет на event, а не на click, кстати почему так?
Что null тут делает вообще, в другом месте это вроде стандартное значение?
> а так, чтобы задействовать уже существующий ассоциации
Так определенно стало понятнее, но `=>` все еще сложно понять.
`@` тоже едва очевидный, но можно понять после объяснения
И все же, почему не парные скобки, а / * для массивов и объектов?
> интерпретация действий пользователя
Речь про ивент листенеры, они есть, да и вообще в view.tree стандартные значения пишутся (судя по `value 0`)
> повторения — инъекция логики в шаблон
Речь про map и вроде вот оно, но я не уверен.
UPD: А, `/` это пустой массив как стандартное значение.
Попробую ответить на все сразу.
Вступление
Я говорил о том, почему $mol, на мой взгляд, в текущей своей форме распространенным стать не может, т.к. у него очень низкая доступность. А не про то, где его расположить на глобальной шкале фреймворков и DSL.
Сначала отвечу фидбеком, потом попробую написать полезные вещи про конкретные аспекты view tree.
Примеры ниже будут от моего лица, но, кажется, они справедливы для большинства frontend разработчиков.
Да. Только новизна сама по себе — не то чтобы положительное свойство (с прикладной точки зрения), это конечно очень весело, но едва продуктивно.
Ок, но форматтеры все еще нужны т.к. договариваться в пулл реквестах и постоянно думать про то, как оформлен код, неудобно. Тут все еще можно написать с маленькой буквы то, что принято писать с большой и поставить 2 пробела, где принято 1.
Тут есть 2 нюанса.
{и писать js до следующей}. Потому что писать js html я уже умею, а фигурные скобочки для переключения синтаксиса — конвенция в куче шаблонизаторов, языков, да и в самом jsRight? ${true ? 'yes' : 'no'}.Аналогичная вещи произошла с elm, если показать случайному фронту https://ellie-app.com/37gVmD7Tm9Ma1, он даже не зная elm по цвету слов и буквам в них опишет, что там происходит. Т.е. если птичий синтаксис оперирует такими же понятиями (функции, аргументы, массивы, объекты, поля, переменные) и одинаково обозначает структуры данных, его сильно легче воспринять, чем принципиально альтернативный подход. (понял большую сразу верно для кучи всего, elm, sass, toml, kotlin, C#, go, vue, т.д). Для $mol и view.tree верно скорее понял примерно ничего, почитал и стало ненамного лучше.
[]для массивов и{}для объектов это делают,/и*— нет, более того, у многих они зарезервированы под деление и умножение (или wildcard), и приклеивать им дополнительные смыслы энергозатратно. Причем в этом же проекте их надо будет мыслить по-старом, ведь не все можно на view tree написать. Не просто так люди со скрипом пишут (если вообще справляются) regex из головы.В данном случае говорим про дизайн языков, я бы выделил 6 критериев (которые все в сущности ведут к одному: инструментом просто решать задачи сразу)
Менее личное и (возможно) более полезное
Не факт что я скажу тут что-то новое, но сейчас создается впечатление, что эти пункты игнорируются.
\nчто-то значит, отступы — нет. Они привыкли что структуры данных открываются и закрываются. Они привыкли к модели родитель\ребенок, а неsubи т.д.$molсоветует компонентный подход или что)$molхвалится стандартной библиотекой компонентов, при этом нет не 1 примера вида: берем$mol_buttonи добавляем ей:active\ убираемborder-radiusс выделенных дат в календаре и т.д. Т.к. дизайн библиотеки компонентов$molне в том, состоянии, чтобы брать ее дизайн как есть, а как его поправить или переопределить — непонятно. Ну а большим компаниям чужой стиль тем более не нужен, так что для них$mol— в лучшем случае "низкоурованеый фреймворк".Итого
Скорее всего в
$molесть куча хороших идей и решений, но за ними надо непонятно где и куда копать, а его подача мотивации не прибавляет.Сходу не могут понять ни люди, ни анализаторы кода для js (фичи ide rip, литеры rip).
Повсюду какие-то слеши в разные стороны, спецсимволы, чтобы указывать на типы.
Это получить свойство Title из $mol_view или объявление его на $mol_heros или что вообще?
UPD: Даже посмотрев во что это компилится, ощущения что это хороший дизайн не стало.