заниматься Software engineering в котором engineering не пустой звук
и
кто-то должен и сами движки делать
это вещи немного разные. Теоретическое CS мало пригодно для непосредственного написания движков, особенно теория Б. Кое что из теории А, можно применять. Чтобы
Во-первых, кто-то должен и сами движки делать.
Нужно выучить несколько фундаментальных вещей ещё и со стороны математики: 0) Мат. базу под все следующее 1) Аналитическую геометрию 2) Дифференциальную геометрию 3) Теормех(+ ODE) 4) Урматфиз(+ PDE, + функан под совершенные методы), если есть желание писать «рендеринг». 5) МПВ, очень много МПВ(+ функан, под современные методы). Все это учить по говнокоду в сорсах анрилы не самая оптимальная идея из возможных. Все, без исключения мои знакомые кто «пишет сами движки» и в этом хорошо преуспели имели хоть какой-то математический бекграунд.
Очень толковая, половина про то, как работает компьютер,
Эти вещи обычно описывают в книгах по системному программированию, но тут лучше начинать с машин тьюринга и плавно двигаться в сторону amd64 или arm, что больше нужно.
современные студенты не умеют работать с памятью
Студенты никогда не умели работать с памятью. Да и не студенты тоже, никто не умеет работать с памятью, все новое на С и С++ течет, и в ближайшее время эта ситуация меняться не собирается, ибо комитетчикам пофиг, а раст да ещё и в геймдеве не особо силен. Всякие К-фреймворки те же студенты знать не знали и слыхать не слыхивали, по этому можно спокойно забыть и забить. Можно конечно затыкать дырку в тулинге скилом разрабов но это очень экстенсивный путь.
И она представитель тяпляпа, не вылизанной поделки.
Она 2д и в ней почти ничего нет. Такое тяп ляпом писали на флеше лет 10 назад, и оно не лагало. С чего бы сейчас такому лагать?
когда примитивная игрушка
Примитивная игрушка, которая очень уныла зато быстро работает не нужна не кому. Она плохо продается и слишком дорого стоит. Сделать ляп ляп и в продгораздо экономически целесообразнее. Никто никогда не будет оптимизировать больше чем под железо ЦА, на это просто нет денег. И кривизна рук тут далеко не всегда при чем.
что на мобильных юнити играх свет клином не сошелся.
ну как раз таки сошёлся
кто-то должен и сами движки делать.
экономически не целесообразно если вы не рокстар. Сейчас бы писать свой движок для убийцы сабвей серфа.
Поэтому мой совет начинающим, особенно студентам у кого есть свободное время — пишите свои велосипеды
пропущено слово «не».
потому что там C++
так себе аргумент, тамошние плюсы страшнее атомной войны. Этим советом обрекаешь их на веки вечные копатся в жутком говнокоде.
время не является тем за что платят.
это уже просто смешно. Вы сейчас заканселяли все почасовки.
Это и была изначальная концепция акторов, которую Кей и реализовал в виде ООП в Smalltalk
Ноуп, когда вы написали kakoitoactorref ! kaoitomessage вы точно не понимаете какой каскад событий произойдет и кто будет на месте этого самого актор рефа, слишком много слоев индерекции. При наличии какого — нибуть динаического роутинга и прочей изменяемой топологии и хитрой логики в компайлтайме понять что происходит методом беглого просмотра невозможно. ты дергаешь один актор, а он другие, а те в свою очередь ещё другие и так далее, и когда оно завершится, сколько при этом акторов будет поднято, какая полная трассировка будет — это все в общем случае непонятно. Нужно очень много инжиниринга чтобы поверх этого делать что-то более менее читаемое.
Само же ООП так и осталось даже в учебниках — способом избавления от сложности управления общим состоянием системы.
акторы не про это, акторы линеаризуют сообщения каким-то образом. Если вы загляните в викепедию то увидите что в определении даже нет состояния. Они НИКАК не решают проблему выяснения того что произойдет при посылке какой-то команды, вообще никак. Как-то решают мощные типы и алг. эффекты, там хоть прокликами в IDE можно ограничить дерево потенциальных вариантов развития событий до приемлимого для анализа без запуска.
Сообщения Страуструп преватил в методы, и т.д.
Страуструп делал си с классами, и судя по всему делал без излишних заморочек «как получится», ибо та самая линеарзиция сообщений была благополучно провтыкана.
мало того, как показала практика — она избыточна для большинства задач.
в _любой_ задаче где есть IO-bound задачи вам нужен какой-то достаточно эффективный механизм передачи управления другой задаче которой ждать не нужно, иначе ваша программа будет то и делать что находится в ожидании, гуи будет подвисать при походе на диск и в веб сервисы и так далее. Т.е. любое приложение которое веб сервер, да и вообще как-либо систематически работает с тормозным вводом — выводом имеет необходимость в таком механизме, и ваша «практика» тут ничего не доказывает. Да и на любой мало-мальски хорошо оплачиваемой дажва или скала вакансии вас точно будут спрашивать про JMM, happens-before, волатайлах, синхронайзедах, атомиках, ещё нескольких фреймах про многопоточке, как оно все это работает и так далее. На синьорных позициях это вообще маст-хэв.
У вас интересное определение слова «норм». Т.е. вам норм, когда вы беглым взлядом на код(не держа всю систему в глове) не можете гарантированно определить куда уйдет какое сообщение и к какому изменению глобального состояния приведет? Голые акторные модели не дают никаких средств по этому поводу. Там необходимо воротить очень много инжиниринга поверх акторов.
Зайду с других козырей, как в этом править баги? Пока все нейрохайповые системы даже в респектабельных местах: мы никак это не можем исправить, стродайте.
ідеальний для певних типів задач
Да, для задачи создать наиболее нечитабельный код который выглядит читабельным лучше кандидатов не найти.
Потому что много голодных студенто в из большого количества вузов демпингуют цены, а QA особоенно ручное, это наиболее низкое по порогу входа дело.
это уникальный язык
найти что-то настолько низкокачественное это ещё нужно постаратся в этом плане жаваскрипт это то дно, которе ещё никто не пробил.
так как исчезает дополнительное согласование API и поведения.
ну это достигается совершенно другими способами, и одному делать все нет совершенно никакой необходимости, вот например как это делает protoforce io. Просто пишете протокол на языке для описания протоколов и забиваете на согласование API, потому что язык вам это все дело сгенерирует.
Таким образом, понимание всех плюсов и минусов клиента поможет в формировании архитектуры приложения.
бекенду по барабану кто и откуда его дергает главное чтобы протокол соблюдал.
Шире выбор проектов.
не достоинство, никогда бы не хотел работать с жс.
с рантаймом, иначе будут проблемы.
Ммм, интересно. вот чего то в джаве байткод не поддерживает дженерики от слова совсем, тем не менее в джаве они есть, а в скале ещё и ХКТ наворотили, а на макросах и ещё и зависимую типизацию. И проблемы там имеют свои пути решения. Почему тогда не сделать типчики в биме? Не ужели всем так нраится заниматься аудитом неявных контрактов по поводу и без?
Он был бы очень даже ничего, если бы осилили его нормально типизировать.
Суперлегка модель для розуміння та використання, принаймні зараз так здається.
Это только от части так. Модель акторов достаточно простая для поверхностного ознакомления, но писать на ней что-то прикладное да и большое очень сложно. Скалисты вон уже убедились из юзеджа акки во всех местах, что акторы на самом деле — сложно(вы сразу, с порога превращаете свою систему либо в совокуность timed automata либо hybrid automata, которые даже симулировать проблематично, не то что проверять на работоспособность). Актор очень простая штука, она просто каким-то образом линеаризует сообщения, при том эти сообщения не типизированные. Это все что актор делает, но на этом не исчерпываются все задачи которые приходится решать в рамках работы с многопоточкой, да и вообще, потому что кроме акторов в эрланге/эликсире нет ничего.
Потеряли аппаратный кошелек — легко можете восстановить ее через другой софт кошелек, который подерживает формат генерации этой сид фразы, обычно там BIP-39.
запомнить сид фейз ненадежно, бекапить ненадежно. И бетховеном крипта не ограничивается.
1) stackoverflow.com/questions/tagged/java
2) Просит ли? www.tutorialspoint.com/compile_java_online.php выдает
$javac HelloWorld.java
$java -Xmx128M -Xms16M HelloWorld
max = 0.9969690961547211
min = 5.236547651865653E-4
avg = 0.5112746316201295
Да в принципе любая более менее ценная крипта недешевое удовольствие, ни одна из полных(архивных) нод не влезет в ноут, да и гигахеши необходимые там для майнинга выжать не получится.
Есть KMS as service. Есть хардварные токены, крипта «хранится» там, но если потеряете — никто не вернет вам ничего.
В финтех конечно же, там платят больше, просят меньше. Если есть мозги и себя не жалко, в ФААНГ и прочие большие технокомпании.