Справедливости ради, я не вижу тут особого противоречия. Ничто не запрещает такому шасси перераспределять нагрузку, снимая её с оператора. В примере в статье экзоскелет — 9кг, плюс пульт (?) сапёра 20 кг. Если экзо заберёт на себя вертикальную нагрузку от пульта и перераспределит её частью равномерно на тело, частью перенесёт в горизонтальную нагрузку при движении ног — он КМК вполне решит свою задачу. К слову, полные латы рыцаря в средние века весили что-то около 25-30 кг, и в них вполне можно было бегать.
С геймдевом не сильно знаком, но КМК между низким и высоким уровнем лежит довольно широкий "овраг". Низкоуровневость и управляемость С++ нужна мало где, но при этом для скриптов хотелось бы оптимизаций и компайл-тайм проверок. Для этого, как я понял, любят использовать C#, но он требует довольно объёмный рантайм. Интересно было бы посмотреть на язык с более "человеческим" синтаксисом, транспилиремый в С или С++.
О да. Quake, с которой начался мой серьёзный интерес к программированию. Вытащенные не помню откуда распаковщик и компилятор QuakeC. И первый мод, склёпанный на коленке в старшей школе, добавлявший альтернативные режимы стрельбы. Помню, как до меня дошло сделать два отдельных impulse, один на нажатие "второго курка", второй на отпускание.
Насчёт стрелок согласен. А вот насчёт Home/End/PgUp/PgDn через Fn я бы поспорил. Лично для меня стало очень удобно после небольшой тренировки, не нужно пальцы со стрелок при навигации никуда двигать.
Когда я вижу очередную такую иллюстрацию, я чувствую, что обо мне заботятся. Мне кажется, что всё будет хорошо. Что мир не такой сложный, как может показаться.
Когда я вижу очередную такую иллюстрацию, у меня автоматом возникают ассоциации с бессмысленными улыбками и дебиловатыми песенками ТВ-рекламы.
Причина — банальная: мы уже привыкли к цифровым приложениям и сенсорным дисплеям, поэтому нам больше не нужна имитация аналогов из реальной жизни. Кроме того, чем проще дизайн, тем быстрее такой контент потребляется — а мы пропускаем через себя огромное его количество.
Мне почему-то кажется, что причина гораздо банальней. У такого стиля гораздо ниже требования к квалификации художника для получения приемлемого результата.
и заставить встроенные типы их реализовывать. Тогда была бы доступна масса ништяков вроде пользовательских типов как ключей хешмапа, обобщённых арифметических алгоритмов и т.п.
luajit это отдельная реализация. Вполне возможно, что заменять её на референсную оказалось более проблемно, чем портировать JIT. Но всё равно немного странно, да.
По моему опыту, "митап" у кофе-машины лучше по двум причинам.
Во-первых, пятая точка, оторванная от стула. Т.е. ты явно вышел из контекста набивания кода, копания в документации, отладки etc. etc. Остаётся только обдумывание проблемы. Во-вторых, на таких "митапах" атмосфера неформальная, и проблему если обговаривают, то свободно, как удобно.
А вот всякие формальные митинги — лютая дичь. Куча народу, которые просто втыкают, пока 2-3 человека вслух решают свои вопросы. Я в таких случаях часто "отключаюсь" от разговора и делаю что-то своё. Максимально контрпродуктивная трата времени.
Спасибо за поправки. Я специально взял даты официальных стартов проектов. SpaceX тоже ведь не "с нуля" вели разработку, а скорее всего воспользовались опытом космической программы.
В случае с Windows 10X особенность была в том, что Microsoft пыталась реализовать запуск Win32-приложений в контейнерах (песочницах), как это работает с UWP-приложениями. Задумка была в том, что ОС тогда сможет более эффективно контролировать работу приложений, плюс решается вопрос безопасности (был бы внедрен контроль за тем, к чему приложения получают доступ).
Чертовски обидно, что это не реализовали. Вообще же интересно, насколько было бы сложно реализовать полную виртуализацию всего юзерспейс АПИ. Натыкался в интернете, что попытки уже были, и вердикт тогда был таков, что требуется виртуализировать чуть менее 300 функций.
Немного оффтоп. Другой выбешивающий дизайн - огромная анимация во весь бэкграунд заглавной страницы сайта, сочетающаяся с максимально тупыми фразами, и основной функциональностью сайта, спрятанной чёрт-те куда.
С одной стороны, SpaceX запустил первую ракету в 2008м, через 6 лет после основания. Программа SLS стартовала в 2011м и планирует запуск в ноябре 2021го, через 10 лет. Сроки вроде как сопоставимые, можно даже сделать скидку на класс ракеты. С другой - SLS пока вообще никуда не летала, и ресурсов на её разработку вбухано сильно больше, при нулевом на данный момент выхлопе. Может им стоит всё же озаботиться инженерной частью, а не маркетингом и брошюрками.
Справедливости ради, я не вижу тут особого противоречия. Ничто не запрещает такому шасси перераспределять нагрузку, снимая её с оператора. В примере в статье экзоскелет — 9кг, плюс пульт (?) сапёра 20 кг. Если экзо заберёт на себя вертикальную нагрузку от пульта и перераспределит её частью равномерно на тело, частью перенесёт в горизонтальную нагрузку при движении ног — он КМК вполне решит свою задачу. К слову, полные латы рыцаря в средние века весили что-то около 25-30 кг, и в них вполне можно было бегать.
Тут вы правы. Но всё равно интересно, почему только примитивные типы и только в unsafe контексте. У того же stackalloc ограничения не такие жёсткие.
Интересно, откуда такие ограничения. По сути, пример выше эквивалентен чему-то вроде
но отдельными полями можно, а массивом нельзя.
А появилась ли возможность вставлять массивы фиксированного размера в структуры и классы как поля by value? Что-то вроде
С геймдевом не сильно знаком, но КМК между низким и высоким уровнем лежит довольно широкий "овраг". Низкоуровневость и управляемость С++ нужна мало где, но при этом для скриптов хотелось бы оптимизаций и компайл-тайм проверок. Для этого, как я понял, любят использовать C#, но он требует довольно объёмный рантайм. Интересно было бы посмотреть на язык с более "человеческим" синтаксисом, транспилиремый в С или С++.
О да. Quake, с которой начался мой серьёзный интерес к программированию. Вытащенные не помню откуда распаковщик и компилятор QuakeC. И первый мод, склёпанный на коленке в старшей школе, добавлявший альтернативные режимы стрельбы. Помню, как до меня дошло сделать два отдельных impulse, один на нажатие "второго курка", второй на отпускание.
Насчёт стрелок согласен. А вот насчёт Home/End/PgUp/PgDn через Fn я бы поспорил. Лично для меня стало очень удобно после небольшой тренировки, не нужно пальцы со стрелок при навигации никуда двигать.
Когда я вижу очередную такую иллюстрацию, у меня автоматом возникают ассоциации с бессмысленными улыбками и дебиловатыми песенками ТВ-рекламы.
Мне почему-то кажется, что причина гораздо банальней. У такого стиля гораздо ниже требования к квалификации художника для получения приемлемого результата.
В статье то рубли, то доллары, то йены. Это специально чтобы запутать?
К сожалению, "костыль" со списками типов таки просочился в релизную версию. Хотя предложение сделать интерфейсы вроде
и заставить встроенные типы их реализовывать. Тогда была бы доступна масса ништяков вроде пользовательских типов как ключей хешмапа, обобщённых арифметических алгоритмов и т.п.
Однако, увы. Решили сделать "как проще".
luajit это отдельная реализация. Вполне возможно, что заменять её на референсную оказалось более проблемно, чем портировать JIT. Но всё равно немного странно, да.
А чем бы это помогло? Выхлоп системы охлаждения в подвал не спрячешь.
Для этого процесс сериализации отделяют от самого сериализуемого объекта. Один из примеров — библиотека Cereal.
Всего-то фуксия.
По моему опыту, "митап" у кофе-машины лучше по двум причинам.
Во-первых, пятая точка, оторванная от стула. Т.е. ты явно вышел из контекста набивания кода, копания в документации, отладки etc. etc. Остаётся только обдумывание проблемы. Во-вторых, на таких "митапах" атмосфера неформальная, и проблему если обговаривают, то свободно, как удобно.
А вот всякие формальные митинги — лютая дичь. Куча народу, которые просто втыкают, пока 2-3 человека вслух решают свои вопросы. Я в таких случаях часто "отключаюсь" от разговора и делаю что-то своё. Максимально контрпродуктивная трата времени.
wormball
akaAzazello
striver
Спасибо за поправки. Я специально взял даты официальных стартов проектов. SpaceX тоже ведь не "с нуля" вели разработку, а скорее всего воспользовались опытом космической программы.
Чертовски обидно, что это не реализовали. Вообще же интересно, насколько было бы сложно реализовать полную виртуализацию всего юзерспейс АПИ. Натыкался в интернете, что попытки уже были, и вердикт тогда был таков, что требуется виртуализировать чуть менее 300 функций.
Немного оффтоп. Другой выбешивающий дизайн - огромная анимация во весь бэкграунд заглавной страницы сайта, сочетающаяся с максимально тупыми фразами, и основной функциональностью сайта, спрятанной чёрт-те куда.
С одной стороны, SpaceX запустил первую ракету в 2008м, через 6 лет после основания. Программа SLS стартовала в 2011м и планирует запуск в ноябре 2021го, через 10 лет. Сроки вроде как сопоставимые, можно даже сделать скидку на класс ракеты. С другой - SLS пока вообще никуда не летала, и ресурсов на её разработку вбухано сильно больше, при нулевом на данный момент выхлопе. Может им стоит всё же озаботиться инженерной частью, а не маркетингом и брошюрками.