Pull to refresh
-8
0.2
Send message

Зря вы так про JIT, в целом полностью с вами согласен во всех тезисах, и философско-политических в том числе. И очень радостно что есть люди с такой позицией. Но JIT удобная вещь, lua, js, без них очень сложно делать игры. Они все кривые, ужасные и полное г..но по сравнению с с++ или даже паскалем, но решают одну важную вещь, позволяют загрузить(скачать) и исполнить кусок кода. А это невероятно удобно для модов и различного рода ДЛЦ. В многих предметных областях есть задачи где не нужен код всей системы, но нужно отдать на откуп часть поведения людям на стороне. Понятно что интерпретатор не есть JIT, но как только начинается интерпретация сразу хочет JIT что бы оно хоть как-то по перфу работало.

Идея в том что бы брать что-то хорошее из одной системы и адаптировать для другой системы. Если не подходит чистый Дракон, можно сделать же какую-то подходящую модификацию на основе идеи дракона о том что одинаковые логически схемы выглядят одинаково. Как мне видится нодовый редактор квестов, это обычный нодовый редактор, только с автоматическим позиционированием элементов. Возможно это нельзя сделать в полной мере, возможно вообще нельзя, у меня еще не было возможности проработать эту идею.

Точно не легко, такую работу вижу каждый день, без минимальной цветовой раскраски невозможно работать, в экселе это решали заливкой ячеек. И мысль пока развивается в сторону примерно такого редактора, но никто не пробовал насколько удобно будет им пользоваться, это красиво выглядит когда в демке примерно 1% от необходимого контента, что будет когда добавят остальные 99% не понятно, но думаю что в любом случае будет лучше, если не давать пользователям свободно размещать блоки и связи, а контролировать геометрическое расположение блоков будут правила как в Драконе.

Попробуйте в коде задать граф квестов и потом научить гейм-дизайнеров его делать, некоторые структуры гораздо проще задавать визуально, графы это одна из них, дракон это грубо говоря правила упорядочивания графа, что бы он не превращался в огромного макаронного монстра.

Даже табличное представление квестового графа это полная ж... ГД тут же начинают плакать и просить цветовую подкраску что бы хоть как-то читать это.

Йо вэй, денег просят государственных, а технологии будут частными. Национализация расходов и приватизация прибылей. Так не годится. Если МЦСТ хочет денег государственных, то и результаты ее работы то же должны принадлежать государству, то есть быть открытыми. Это касается всех и тех кто хочет на RISC-V процессоры делать. Конечно же нужно поддерживать микроэлектронику. Но порождать монополию то же нельзя. У МЦСТ отличный план: сначала дайте денег, потом примите закон что бы покупать можно было только наше, потом перепишите весь софт, а дальше мы будем диктовать цены и продавать за столько за сколько захотим, когда займем нишу.

С компиляцией последнее время почти нет проблем, прекомпиленые хидеры это понятно, сейчас добавилась инкрементальная линковка. Плюс компилируется то что менялось, плюс появились очень многопоточные процессоры. Ну и мне даже иногда нравится задержка перед запуском программы, те 30-40 секунд что обычно работает компилятор хватает что бы подумать что будешь писать дальше. Еще в студии очень удобная фича компилировать только файл на котором курсор стоит.

"ноги простреливаются" проблема сильно преувеличена чем она есть на самом деле. Там вот выше чет про memcpy терли, даже вчитываться не стал, обычно такой код не пишется, обычно работа идет на несколько более высоком уровне, если есть данные они скорее всего хранятся в контейнере, а если нужно скопировать контейнер, std::copy, std::transform, да тонкие оптимизации так не сделаешь. Для тонких оптимизаций есть профилировщик и опять же в 90% случаев проблема будет в архитектуре или алгоритме. Но если у вас супер критичный код и прям вот надо выжать все, ну ок, почитай справку и сделай все аккуратно. Так то и до асма можно дойти при желании. С++ сильно мультипарадигменный. Опять же проблема современного программирования, приходится постоянно переключаться с разных языков, что-то на питоне сделать по автоматизации, что-то на нативе(objective c, java), пол игры вообще на lua написано, система сборки на cmake, держать в голове тонкости работы 5-6 языков не возможно, как минимум в моей, поэтому ок гугл, хау то... и поехали, все мы в той или иной мере фулстековерфлоу программисты.

BGL - кровь из глаз, кто же спорит, boost.spirit - ну нахер, апи curl - хочется пойти выйти в окно, но есть cpr. Подключить библиотеку - да сдохнуть можно было еще лет 10 назад, но появился cmake, а потом конан и vcpkg стало как-то очень полегче, но все равно, есть Tesseract, от которого много что зависит на тему распознавания, он начал под mac-arm64 собираться из коробки месяц назад, до этого приходилось патчить и до сих пор в vcpkg либ у которых в портфайлах !arm написано валом. Но понимаете в чем дело BGL то есть и он работает, и аналогов по спектру решения задач не особо много, скажем почти нет, а какая альтернатива в других языка? Сесть написать свои алгоритмы, а потом годами в них ловить ошибки на корнеркейсах?

Альтернатива это всегда хорошо, не было бы руби-на-рельсах, пипа, никто бы и не почесался в с++ на тему пакетного менеджера. Питон очень хорош для автоматизации и прототипов, даже если взять qt, я не буду больше никогда на виджетах ничего писать, скорее всего, потому что qml дает больше и лучше, а там с++ загнан под капот и вообще все на js. Альтернативы дают новые подходы которые заставляют развиваться мир с++ и самые успешные альтернативы дают тебе не замену с++, а дополнение с++. Они не вместо, а они вместе. Ни для кого не секрет что под капотом питона все так или иначе использует с++, у явы есть JNI.

Что пишу, в основном геймдев: движки, внутренние редакторы и различные утилиты. Геймплей, понятно, что это будет или скриптовый язык или квестовый граф, в общем то что можно быстро и легко переделывать, а вот различная работа с ресурсами, рендер, сеть и прочее это будет или натив или с++. Вот что-то такое и пишу, делаю все что бы гемплей командам жилось хорошо и беззаботно. В геймдеве работы много и она разная, можно менять специализацию при желании. Лично по-моему опыту уровень задач и их качество зависит от рук, а не от технологии, Языки, фреймворки все плюс минус одинаковое. Мне нравится связка C++/qt потому что более менее понимаю как этим пользоваться, плюс есть огромная поддержка с++ со стороны различных сторонних бибилиотек. Ну к примеру есть boost::graph мне не понятно что будут делать специалисты на флуттере если им нужно будет в графе найти остова, с помощью буста это решается щелчком пальца, а там что, сидеть самому писать алгоритмы? Или к примеру иногда приходится делать свой язык под задачу, берешь bison/flex и вперед можно antrl, а на флуттер что делать? Antrl может быть конечно уже и сделали биндинги в Дарт, не следил как-то. Но опять же мне Antrl парсеры меньше заходят, и bison уже умею пользоваться. Мне минимум два раза встречались задачи на использование шаблонизатора, первый раз лет 10 назад для генерации отчетов и печатных форм, второй раз вот совсем недавно что бы дать возможно аналитикам делать выборки по балансу для своих моделей, в обоих случая логично было бы прикрутить скриптовый язык, в одном случае пошел js в другом lua, плюс автоматизацию для тестировщиков писали в одном случае прикрутили биндинг в питон по парсенгу логов перфа с ночных билдов, во втором случае взяли ChaiScript и дали возможность писать тестовые сценарии для фермы мобильных клиентов, на скрипте описывались сценарии для всех устройств. Ну к примеру заходят в бой два клиента и дерутся по определенному сценарию, за бой снимаются логи по перфу и потреблению памяти, а так же насколько у нас баланс сходится. В случае отклонения от референсных значений - алерт. Короче задача скриптования встает очень часто, и для с++ есть куча готовых решений: питон, луа, chaiscript и т.д. Делаю игру мне нужен отладочный UI - беру imgui и вперед. В одном из проектов нужен был профилировщик, сели написали профилировщик, как на дарте вообще это сделать, сначала написать биндинги winapi в дарт потом писать профилировщик? А насколько это долго будет работать у нас 5 минут игры генерили примерно 10 Гб логов(не текстовых, а ETL).

Вот автор статьи говорит про вебсокеты, и зачем после их появления нужен tcp, ну сделайте на вебсокетах пробой NAT через STUN/TURN. Это нужно например что бы экономить сотни тысяч долларов на раздаче DLC для игры. WoT обновления через торрент протокол раздает.

Я про всякое разное убийцы с++ слышу... сколько работаю столько и слышу, сначала был .NET все c# сейчас все убьет, UI только на нем, WinForms лучшее, очень быстро, очень качественно, программирую на с++, потом Flash, все кроссплатформенно, очень низкий порог входа все игры будет писать на нем и программы то же, веб все захватит, программирую на с++, потом электрон, очень круто, очень много разработчиков, очень быстро, все UI только на нем, продолжаю программировать на с++, сейчас вот флуттер, все с++ хана все только на нем, ну... как бы мое отношение понятно ) Нет какую-то нишу себе флуттер займет, как заняли и все убийцы с++ до этого, но с++ никуда не денется еще очень очень очень долго.

" Если бы мне предложили реализовывать его на базе С++, я бы такое запретил. "

Это очень хорошо. Фактически чем больше будет людей разделяющих ваши взгляды тем выше будет моя зп.

Своей команде позволяю писать как хотят, мне все равно, могу читать почти любой код в любом стиле, друг друга пока понимаем, код ревью вести не сложно. Но люди особо и не пишут ничего сложного, никто не рвется писать трехэтажные шаблоны. Сам стараюсь писать максимально просто, остальным то же рекомендую. Когда долго программируешь все равно приходится лезть в чужие библиотеки и так или иначе в них разбираться, со временем становится все равно на код стайл и гайдлайны. Скажу крамольную вещь, у нас сейчас команда 10+ программистов и даже кодстиля нет ), когда приходят новички по началу спрашивают про код стиль, говорю пишите примерно как в коде написано, ну и как-то нормально. На мой взгляд самый лучший способ разработки это не мешать бюрократией и проектировать постфактум, перед реализаций быстро прикинул что как, обсудил минут за 10, потом когда уже функциональность написана и ее много, вот тогда делать проектирование и рефакторить. То есть условно процесс разработки можно построить на два этапа, первый это говнякать прототип, который может и в релиз уйти, а потом уже систематизировать написанный код, уже зная как он работает и какую задачу решает, систематизировать. Причем эти два процесса должны идти все время, так лично по моему опыту получается лучше и быстрее разрабатывать даже достаточно крупные штуки. Беда начинается когда менеджеры вмешиваются и не дают проводить систематизацию: "ну оно же не привезет новых функций зачем работу делать". Более того слишком большое проектирование вначале как правило заканчивается овериндженерингом, а самое неприятное что в процессе реализации как правило приходит понимание что не учли, но так ТЛД уже написано начинают костылить и получается по качеству примерно то же самое что просто наговнякать, все равно набор подпорок и костылей. Так давайте говнякать сразу а потом уже сделаем начисто.

Это все звучит очень спорно и вразрез с общепринятыми подходами, возможно оно работает только у меня и еще у пары коллег, а у других такой подход работать не будет.

Мы используем из нового просто и понятное: optional, atomic, thread, filesystem, лямды, с новым стандартом появились хорошие библиотеки, например magic_enum. Вроде Rust развивается активно. С++ хорош тем что вокруг него есть миллиард библиотек и он работает почти везде.

Работаю уже лет 20(с первого курса) и подхожу к заветной точке 40+, так вот первым моим языком был С++, первым большим фреймворком был Qt, не поверите, но все что изучал еще в школе до сих пор вполне актуально. А самое главное без этого не строится ни один большой проект, автор работает в очень специфичной сфере, судя по примерам, веб-сайты, интернет магазины, мобильные приложения на Flutter, это очень маленькие проекты, это даже не программы в полном смысле, аналоги сайтов визиток популярных в начале 2000. Напишите пожалуйста хотя бы мессенджер без с++ или натива. Только нет вот это я тут взял фреймворк где за меня разрабочики фреймворка прикрутили webrtc сделали обертки в js и меня вот звонок уже идет. Нет, сделайте хотя бы звуковой кодек без си/с++. Про всякую пену типа флеш, электрона, теперь флуттер, слышу уже много лет, сколько работаю столько и слышу. Ну и как программировал UI на Qt, так и программирую. Конечно все эти модные штуки возьмут себе какое-то место под солнцем, хотя флеш вроде сдулся совсем, но с++ никуда не денется очень, очень много времени. А самое приятное что можно вообще не тратить время на новое разрабатывая на с++, ну к примеру появился std::thread, но что системные потоки перестали работать? появилось время можно посмотреть новый стандарт, не появилось пиши как раньше, работать не перестанет. И по перфу готов на с++/qt соревноваться с любой модной штукой. И самое что интересное, уверен в том что на с++ и qt будет реализована любая сколь угодно сложная задача в полном объеме и не упрусь в технологию, в крайнем случае пойду дергать нативное апи системы, будь то андроид, winapi или ios.

"теперь у нас в компании нет разработчиков мобильных приложений на нативных языках" это означает что вы можете решать класс задач только тот который дает флуттер и не больше, обсер произойдет сразу как понадобиться работать с камерой и выжимать перф для нейросетей.

Все так, только вот сложность этого занятия была значительно выше. Собрать что-то написанное с использованием autoconfig тот еще квест.

Благо мы живем не в 2010, а в 2022, когда уже есть CMake, кросскомпиляция, компиляторы которые умеют генерировать код под любую платформу, куча открытого софта и библиотек, если в 2010 годы было вообще непонятно как обеспечить поддержку проекта в хкоде и вижуалстудии, то сейчас это делает щелчком пальца, ну почти. Сложность разработки кроссплатформенных программ понизилась в разы, если не на порядки. Даже для внутренних программ поддержка мака и виндовс считается чем-то самой собой разумеющимся. Так что если будут две конкурирующих платформы станет только лучше. Добавить RISC-V, MIPS и прочее станет значительно проще, чем при переходе от одного монополиста. Сейчас даже поддержка линукса, с его мемными 1,5% процентами пользователей, становится чем-то само собой разумеющимся, не у всех и не всегда, но тем не менее. Даже микрософт уже пилит софт для линукса. Я считаю, и с этим можно спорить, что устойчивость в многообразии.

Если посмотреть на развитие "отечественных" процессоров, то прогресс явно идет, раньше был Эльбрус, который стоил даже не как крыло от самолета, а как весь самолет, купить его было нельзя, ничего на нем кроме базы данных не работало, а по перфу он сливал в десятки раз 10 летним процессорам. Сейчас начали появляться процессоры которые начинают стоить сопоставимых денег, они все еще медленные, где-то устаревшие, но уже не отстают в 10-ки раз и даже тот же Эльбрус можно купить, софт становится актуальным. Прогресс очевиден и это радует, появляется какая-то конкуренция, раньше был один Эльбрус и все. Но лично мое мнение что эльбрусные VLIW ядра это тупиковая ветвь, и даже не потому что VLIW, а потому что целиком пилить архитектуру процессора с трудом может себе позволить даже IBM, все остальные приходят к каким-то стандартам которые общие. Кто будет писать драйвера под Эльбрус? У ARM ядер с этим вопросом лучше, это по факту как-то более менее стандарт, но санкции все дела то же убивают всю идею на корню, как лицензировать архитектуру, если тебе не дают это сделать. Получается что сейчас два подхода и оба в текущем виде тупиковые. Выходы как мне видятся такие, Эльбрусу нужно стать открытым или лицензируемым, появится больше разработчиков, спектр железа станет больше, можно попытаться сделать данную архитектуру некоторым стандартом под которые другие компании будут адаптировать свои решения, писать драйвера и знать что вся эта архитектура не умрет с каким-нить неожиданным банкротством МЦСТ, ведь открытую архитектуру не обанкротить.

Второй выход - переход отечественных процессоров на RISC-V, причем Эльбрус ядра отлично будут смотреться как сопроцессорные ядра для узкого круга задач.

Внезапно "был бы человек, а статью найдем" работает во всех странах мира когда это очень нужно правительству. В данном случае правительство ведет политику подавления других наций и поддержки первенства своей, впрочем в той или иной мере этим занимаются все и шпионажем то же. Так что для китайского народа он герой разведчик, а для американцев шпион предатель. Другое дело что почему-то многие считают что в америке только ангелы и не используют "грязные" методы типа дать наркоты и мочить гаечным ключом пока все не расскажет. Думаю не последнею роль в этом играет пиар заказанный тем самым правительством через различные объекты искусства, попросту: книги, фильмы, журналы и прочее. А еще непонятно почему под подобными новостями комменты типа, "ну да это же правосудие, кто мы такие что бы судить о действие американского правительства", а как только кого-нить на каком-то новосибирском секретном КБ, где разрабатывают ракеты типа Калибров за такое поймают так 100500 комментов, что кровавая гебня мещает жить свободным личностям. Промышленный шпионаж это вообще то чем занимаются с момента появления той самой промышленности, собственно и есть люди которые пытаются этому мешать. И если кто-то думает что в россии нечего красть, он сильно ошибается, всегда полезно знать что делает конкурент, даже если он на текущий момент тебе в чем-то или во всем сильно уступает. Последние три месяца все сильно удивились узнав что оказывается россия умеет начищать морду да еще и очень технологично, откуда же сотни ракет, кораблей, самолетов которые обнаруживают, стреляют и еще регулярно неплохо попадают в цель, у страны которая, все знают, что даже гвозди делать не умеет.

Пора бы уже начать осознавать простые истины, государства ведут конкурентную борьбу наций: кто-то дружит друг с другом против других, кто-то пытается сам, кто-то смерился и знает свое место, кто-то подчиняет других. Еще не бывает бедной власти. Если человек вроде как занимает какой-то значимый пост и внезапно не использует власть в целях личной выгоды, то он или очень идейный, что большая редкость или по факту его власть только номинальная, а есть структуры которые его крепко держат за причинное место и истинная власть у них. Так уж устроен человек что он хочет обладать властью и капиталом что бы увеличивать свою власть и капитал.

Ага, только это не мы по запускам упали, это они выросли. За что заслуживают уважение. Видите к чему приводит коммунистический строй и четкое следование курсу компартии. Ну что обратно в СССР?

Как по мне, так RISC-V интересна тем что есть огромная куча фирм которые делают блоки процессора разного назначения и фактически можно собрать современный процессор как конструкто лего. Алибаба вообще открыла свои ядра которые по их заявлениям быстре ARM A73. https://www.opennet.ru/opennews/art.shtml?num=56010

Есть разные блоки под разными лицензиями, открытые/закрытые.

Плюс софт который уже портирован на данную архитектуру.

Возможно ошибаюсь, но мне кажется что там где идет простое числодробление без сложных переходов, там Эльбрус показывает себя достаточно уверено, но там где появляются условные переходы и наверно кеш-мисы, становится все плохо. Возможно дело в плохом предсказание переходов и загрузке кеша?

Если бы мне дали принимать решение о политике полупроводниковой отрасли, то наверно смотрел в сторону RISC-V.

На мой взгляд в 22 году пора начинать использовать пакетные менеджеры для с++. Например vcpkg, по настроению можно взять конан или любую альтернативу.

Рекомендую посмотреть на Tannoy Gold 5, но учтите что это студийные мониторы и они продаются поштучно. На мой взгляд 30+-тр за пару это хорошая цена. Так же на авито можно найти Yamaha MSP5 Studio по цене 20+-тр за пару. Последние наверно эталон 5-ти дюймовых мониторов ближнего поля(проще говоря настольных колонок). Еще неплохие PreSonus Eris E4.5 (они вроде парой идут). Можно посмотреть в сторону DALI SPEKTOR 2, правда это пасивная акустика, к ней нужно будет раздобыть усилитель, я бы порекомендавал выбрать на алиэкспресе компактный усилитель D-класса типа AIYIMA аудио DAC A5 Pro или AIYIMA A04 TPA3251, там их много разных за разные деньги, играют все примерно одинаково. Еще как вариант JBL 305P MkII. В общем выбор плюс минус в вашем бюджете достаточно большой, особенно если смотреть на рынок б\у техники, начиная года с 90. Акустика хороша тем что почти не деградирует от времени. Если на столе много места то лучше еще и усилитель А-класса, годов начиная с 90-х(техникс, онкио, некоторые модели сони, teac, Yamaha, NAD, Бриг), но тут очень много тонких моментов, основной заключается в том что усилитель должен быть исправным и в отличие от акустики в усилителе есть конденсаторы которые от времени разрушаются. Если бы перед мной стояла задача уложиться в 15 тр, я бы смотрел на б\у, отчасти потому что уже знаю что именно мне понравится. Что точно не стоит брать это советскую акустику, она очень на любителя, плюс не очень качественные материалы которые от времени разрушаются. Хотя мне нравится Радиотехника S30. Из советских усилителей выделяется Бриг, но цена на мой взгляд высоквата в следствие скорее редкости, а не высокого качества, хотя он очень хорош. Мне очень нравятся усилители Onkyo Integra, только именно Integra, это премиальная линейка, там более качественные комплектующие у которых большой запас прочности. Из б\у акустики мне заходит Canton, MB Quart, сам бы смотрел на Canton Ergo (21dc, 200dc). Но вы не ориентируйтесь на мои предпочтения, звук это очень личная тема, то что мне нравится вам может не зайти.

P.S. звук настолько противоречивая тема, что даже сам себе противоречу, т.к. предостерег от советской аккустики, а сам другу на др подарил комплект именно советкой акустики услилитель радиотехника и S30, но это был уникальный случай колонки были в руках у мастера с полным восстановлением всех компонентов, как и усилитель, плюс отделка новым шпоном, что сделало их очень красивыми. И опять же долго их слушал. Не то что бы я такой прям профи что бы на слух что-то услышать, скорее хотелось получить общее впечтление.

Information

Rating
1,984-th
Registered
Activity