Разумеется, на скорости 120 км/ч всё на порядок сложнее (хотя тоже реализуемо), но я больше про неспешную поездку внутри города. Можно, для начала, ограничить максимальную скорость 20 км/ч. У кабриолетов, например, тоже крышу складывать/раскладывать на высокой скорости нельзя.
Если смотреть в этой плоскости, то тоже неоднозначно — конус, валяющийся на дороге, создаёт препятствие и проблемы, однако, целая машина, стоящая на этой дороге, полностью блокирует передвижение по ней в пределах полосы
Как человек поступает? Он видит, что это именно чувак в футболке со знаком STOP, а не знак. Можно формализовать по набору признаков, например, у знака меньше рук (0), ног (1) и голов (0), чем у чувака. Так и робот должен понимать. Для этого не обязательно всё руками писать — уже сейчас с этим справится очередное ChatGPT.
По конусу — машина должна понять, что конус именно на капоте, а не на дороге. Стряхнуть она, в принципе, наверное, может, если подёргается вперёд‑назад, или, если есть возможность, попрыгает (как Mercedes GLS) или пооткрывает‑позакрывает капот, если есть привод. Но все это чревато повреждением ЛКП.
Вообще квадрокоптер‑сателлит с захватом, который большую часть времени сидит‑заряжается на крыше, и периодически сам отлетает для разведки дорожной обстановки, а также для устранения всяких конусов и шутников в футболках, и помогает ловить связь в отдаленных районах — не такая уж невероятная штука. Понятно что бревно с дороги он не уберёт, что‑то мелкое убрать/увидеть, за угол заглянуть — вполне.
В целом, автопилотам не хватает понимания контекста ситуации. Если она будет, наивности, а значит, таких казусов, будет на порядки меньше.
Имхо, если Вы верите в перспективность этой штуки — пробуйте скачать какие‑нибудь открытые экспериментальные данные, и соотнести их с гипотезой‑теорией. Если сходится — можно копать дальше и делать из неё теорию, и уже серьёзно прогонять через неё экспериментальные данные и результаты наблюдений. Если все сходится (и тем более объясняются/считаются всякие «тёмные материи») — можно представлять научному сообществу.
Физика не объясняет устройство мира, она объясняет, как его посчитать. Если Ваша штука делает это лучше нынешних — то это прекрасно
Ну посчитать когда оно долетит до орбиты Сатурна не очень трудно — расстояние есть, ускорение есть, интегрируем и решаем, всё. А вот когда оно долетит именно до Сатурна — тут уже будет кривая траектория, хитро выбранный момент старта и всё такое — здесь уже всё довольно сурово.
Вроде бы с ветвлениями все уже не так плохо как раньше, особенно в SM6. Что касается прерываний — есть смутное подозрение, что это можно эмулировать, если квантовать выполнение кода на GPU на вызовы (например, с частотой 1 кгц) и между этими вызовами делать взаимодействия с устройствами ввода‑вывода.
В про видеокартах есть возможность чуть ли не напрямую забрасывать видеопотоки в память GPU минуя ОЗУ — возможно, через это как‑то можно, с помощью костылей, реализовать ввод данных. Карта захвата и видеокарта стоит в обычном компе, но данные напрямую процессор перекидывает из карты захвата в видеокарту без обработки и помещения в ОЗУ. Через это можно вводить данные в видеокарту, а получать — через её выход HDMI/DisplayPort.
Мы делаем из контроллеров и FPGA такую штуку, которая, с одной стороны имеет Ethernet, PCI слоты и USB, а с другой — HDMI вход и PCIe разъем. Она втыкается в материнский комп с про‑картой и делает вид, что она — карта видеозахвата. Кушаем партию данных с интерфейсов, превращаем в RGB видеопоток, и через PCI шину напрямую закидываем в видеокарту. В видеокарте отрабатывает очередной кусок кода, все данные, которые надо отправить устройствам, выводятся в HDMI и заходят в нашу штуку с интерфейсами. Она эти данные обрабатывет и отправляет устройствам. Разумеется, IO данные будут квантоваться на пачки, по кадрам входящего и исходящего видеопотока. 500 Гц мониторы есть — значит получится передавать буферы 6 Мб 500 раз в секунду. А теоретически пропускная способность HDMI 2.1 может в 960 к/с FullHD.
Ещё бы скорость сравнить на новом железе. По идее, Win95 по современным меркам — пушинка, даже в кэш процессора влезет. С другой стороны, ни x64, ни современных инструкций, ни современных драйверов к ней нет...
Я уже давно жду эмулятор x86 под GPU, чтобы на каждом ядре было по виртуальной машине — итого 15 000 рабочих мест (или просто ОС) на одной видеокарте. Сейчас видеокарты умнее, может быть, это уже не так невозможно, как раньше. А вот рациональность под вопросом — Xeon Phi ведь не просто так закрыли.
У ПК сейчас нынче есть только одно преимущество и использование (ЗА ПРЕДЕЛАМИ РАБОТЫ какой бы то ни было) - соревновательные игры
VR забыли — годные синглы тоже требуют хорошего железа. Игры со всякими модами/дополнениями и прочим. Ну и возможность кастомизации рабочего/игрового места всякими экранами, рулями, моторизированными креслами и прочими штуками (хотя это уже исчезающе малый процент).
ИМХО, когда технология доходит до пика развития, она начинает развиваться в сторону украшательств и второстепенных фишечек. Кнопочные телефоны в конце своего пути пестрили разнообразием форм. Автомобили уже давно обрастают фишками и украшательствами, но принципиально не меняются.
И вот — смартфоны начинают петь свою лебединую песню разнообразием форм, чтобы потом уступить место AR‑устройствам
int* написать проще, чем std::shared_ptr<int>. Поэтому опасность удобнее и лаконичнее безопасности. Это проблема
Я рассуждаю следующим образом. Что мы могли бы сделать с языком, если наша задача предоставить сообществу разработчиков удобный, эффективный и безопасный инструмент?
Сломать обратную совместимость и сделать так, что int* — это и есть std::shared_ptr<int>, а для небезопасного указателя сделать std::unsafe_ptr<int>. Тогда получится, что безопасно писать удобнее, а небезопасно — неудобнее. Профит. Минус: мы тотально уничтожили обратную совместимость, да ещё и запутали разработчиков.
Сохранить обратную совместимость, но сделать так, что новый безопасный указатель проигрывает конкуренцию по эргономике небезопасному указателю - это то, что сделано сейчас. Вот это вот std::shared_ptr<int> - это неудобная дичь.
Сохранить обратную совместимость, но сделать так что новый указатель выигрывает конкуренцию по эргономике небезопасному указателю. Это будет стимулировать разработчиков использовать его. Это идеальный вариант. Проблема в том, что сложно придумать что-то лаконичнее, чем звёздочка *. Я понятия не имею, что это может быть.
Сохранить обратную совместимость, но сделать так что новый указатель не проигрывает конкуренцию по эргономике небезопасному указателю. Это не будет стимулировать разработчиков использовать его, но и не будет отталкивать. Как? Это уже дискусионный вопрос. Самое главное, что должно быть обязательно — эта форма не должна быть менее удобной, чем *. В рамках мозгового штурма можно накидать предлагаемые варианты:
int`
int@
int^ (занят C++ CLI)
int+
int$
int_ptr (добавление постфикса _ptr к любому типу делает его безопасным указателем)
Ничего не добавлять, но обязать встраивать в компилятор ИИ‑анализатор, который будет палить потенциальные неочевидные места, где int* выстрелит тебе в ногу и выкидывать варнинги — то, что сейчас кажется безумием, в будущем будет нормой.
Ещё что-нибудь, что не будет требовать писать жирные::__монструозные<констр>(укции) const.
Да, лезть в синтаксис с неочевидной фигнёй, наверное, не круто. А звёздочка — она разве очевидная? Она привычная, но не очевидная. Звёздочка есть часть синтаксиса, и она состоит из одного символа. Конкурировать по эргономике с ней может только то, что не сложнее. Поэтому, как бы неприятно это не было, это может быть только ещё один какой‑то символ. Да, это не так очевидно для тех, кто видит это в первый раз. Но C++ — это не про низкий порог вхождения, наверное. Хотя может я ошибаюсь.
Я не думаю, что моё предложение прям хорошее, и сам в нём не особо уверен, это просто размышления. Это субъективщина.
Обращаю внимание: утверждение о том, что текущая реализация плоха, и утверждение о том, как это, по моему субъективному мнению, можно было бы сделать лучше — это два разных утверждения. И даже если моё предложение неудачно — из ложности второго утверждения не следует ложность первого. Логика.
Мне часто приходится писать на C++, хотя да — это далеко не основной язык, которым я пользуюсь. В основном я хожу туда за числодробилками и/или 3D‑графикой.
Можно подумать за пределами c++ разделяемое владение никому не нужно (или наоборот, всем нужно только и исключительно оно, поэтому shared_ptr там опущено и принимается по умолчанию), как и блокировки.
Это частности, на примере которых я объясняю непродуманность и неудобность нововведений языка.
Я не говорю «частное владение нужно» или «частное владение не нужно», я не говорю «блокировки нужны» или «блокировки не нужны».
Я говорю, что в язык C++ блокировки были вставлены бездумно и неудобно, я говорю, что разделяемое владение было сделано бездумно и неудобно. И почти всё новое, что они туда засунули, они засунули бездумно и неудобно.
Ещё раз, само то, что засунули — хорошо, то каким именно способом засунули — плохо.
Вот и не хотят. Вот и не пишут. Вот и получается небезопасно. Об этом и речь. Надо чтобы вероятность захотеть написать безопасно была выше, чем вероятность захотеть написать небезопасно.
Более‑менее неплохой пример — то, как это сделано в C#. Я могу писать только безопасно. Если я хочу писать опасно, я сначала должен зайти, поставить галочку
потом написать
unsafe
{
}
И только внутри мне позволят творить опасные опасности. А для __makeref и __refvalue вообще не показываются автокомплиты. Небезопасному коду мешает и семантика языка, и компилятор языка, и среда разработки. А безопасный код пишется проще.
А в C++ наоборот: если я хочу писать опасно, я просто пишу * и &. Если же я хочу писать безопасно, мне надо std::shared_ptr constexpr const const std::lock_guard.
Я не говорю что такой подход идеальный, просто в нём вектор удобства повернут в нужную сторону — удобнее писать безопасно, чем небезопасно.
Речь то не про конкретно приведение типов, а про то, что почти всё новое в C++ сделано неудобно. С каждым разом от тебя хотят всё больше и больше __всяких:::::::слов, <std::букв> и constexpr [[std::вырвиглазных]]:::<<<<конструкций___t>>> constexpr, апеллируя к Безопасности с большой красивой буквы std::Б.
30 лет развития C++ - это когда вместо std::string doit(std::string param); нужно писать [[nodiscard]] constexpr auto doit(std::string_view param) noexcept -> std::string;
Это что вообще за дичь? Зачем так делать? Зачем они пытаются догнать брейнфак? Им там скучно?
Разумеется, на скорости 120 км/ч всё на порядок сложнее (хотя тоже реализуемо), но я больше про неспешную поездку внутри города. Можно, для начала, ограничить максимальную скорость 20 км/ч. У кабриолетов, например, тоже крышу складывать/раскладывать на высокой скорости нельзя.
Если смотреть в этой плоскости, то тоже неоднозначно — конус, валяющийся на дороге, создаёт препятствие и проблемы, однако, целая машина, стоящая на этой дороге, полностью блокирует передвижение по ней в пределах полосы
Как человек поступает? Он видит, что это именно чувак в футболке со знаком STOP, а не знак. Можно формализовать по набору признаков, например, у знака меньше рук (0), ног (1) и голов (0), чем у чувака. Так и робот должен понимать. Для этого не обязательно всё руками писать — уже сейчас с этим справится очередное ChatGPT.
По конусу — машина должна понять, что конус именно на капоте, а не на дороге. Стряхнуть она, в принципе, наверное, может, если подёргается вперёд‑назад, или, если есть возможность, попрыгает (как Mercedes GLS) или пооткрывает‑позакрывает капот, если есть привод. Но все это чревато повреждением ЛКП.
Вообще квадрокоптер‑сателлит с захватом, который большую часть времени сидит‑заряжается на крыше, и периодически сам отлетает для разведки дорожной обстановки, а также для устранения всяких конусов и шутников в футболках, и помогает ловить связь в отдаленных районах — не такая уж невероятная штука. Понятно что бревно с дороги он не уберёт, что‑то мелкое убрать/увидеть, за угол заглянуть — вполне.
В целом, автопилотам не хватает понимания контекста ситуации. Если она будет, наивности, а значит, таких казусов, будет на порядки меньше.
Имхо, если Вы верите в перспективность этой штуки — пробуйте скачать какие‑нибудь открытые экспериментальные данные, и соотнести их с гипотезой‑теорией. Если сходится — можно копать дальше и делать из неё теорию, и уже серьёзно прогонять через неё экспериментальные данные и результаты наблюдений. Если все сходится (и тем более объясняются/считаются всякие «тёмные материи») — можно представлять научному сообществу.
Физика не объясняет устройство мира, она объясняет, как его посчитать. Если Ваша штука делает это лучше нынешних — то это прекрасно
Квантовая теория поля передаёт привет :)
Ну посчитать когда оно долетит до орбиты Сатурна не очень трудно — расстояние есть, ускорение есть, интегрируем и решаем, всё. А вот когда оно долетит именно до Сатурна — тут уже будет кривая траектория, хитро выбранный момент старта и всё такое — здесь уже всё довольно сурово.
То железо очень живучее, гораздо качественнее нынешнего. Вполне могло дожить. Но да, практического смысла все равно мало
Добавлю — с большими экранами долго работать лучше мышкой, ибо руками быстро устанешь размахивать
Вроде бы с ветвлениями все уже не так плохо как раньше, особенно в SM6. Что касается прерываний — есть смутное подозрение, что это можно эмулировать, если квантовать выполнение кода на GPU на вызовы (например, с частотой 1 кгц) и между этими вызовами делать взаимодействия с устройствами ввода‑вывода.
В про видеокартах есть возможность чуть ли не напрямую забрасывать видеопотоки в память GPU минуя ОЗУ — возможно, через это как‑то можно, с помощью костылей, реализовать ввод данных. Карта захвата и видеокарта стоит в обычном компе, но данные напрямую процессор перекидывает из карты захвата в видеокарту без обработки и помещения в ОЗУ. Через это можно вводить данные в видеокарту, а получать — через её выход HDMI/DisplayPort.
Мы делаем из контроллеров и FPGA такую штуку, которая, с одной стороны имеет Ethernet, PCI слоты и USB, а с другой — HDMI вход и PCIe разъем. Она втыкается в материнский комп с про‑картой и делает вид, что она — карта видеозахвата. Кушаем партию данных с интерфейсов, превращаем в RGB видеопоток, и через PCI шину напрямую закидываем в видеокарту. В видеокарте отрабатывает очередной кусок кода, все данные, которые надо отправить устройствам, выводятся в HDMI и заходят в нашу штуку с интерфейсами. Она эти данные обрабатывет и отправляет устройствам. Разумеется, IO данные будут квантоваться на пачки, по кадрам входящего и исходящего видеопотока. 500 Гц мониторы есть — значит получится передавать буферы 6 Мб 500 раз в секунду. А теоретически пропускная способность HDMI 2.1 может в 960 к/с FullHD.
Ещё бы скорость сравнить на новом железе. По идее, Win95 по современным меркам — пушинка, даже в кэш процессора влезет. С другой стороны, ни x64, ни современных инструкций, ни современных драйверов к ней нет...
Я уже давно жду эмулятор x86 под GPU, чтобы на каждом ядре было по виртуальной машине — итого 15 000 рабочих мест (или просто ОС) на одной видеокарте. Сейчас видеокарты умнее, может быть, это уже не так невозможно, как раньше. А вот рациональность под вопросом — Xeon Phi ведь не просто так закрыли.
Win+Shift+S сохраняет скриншоты вроде бы
Мне кажется, или «комбинация парадигм (или их частей)» — не есть «отказ от парадигм»?
VR забыли — годные синглы тоже требуют хорошего железа. Игры со всякими модами/дополнениями и прочим. Ну и возможность кастомизации рабочего/игрового места всякими экранами, рулями, моторизированными креслами и прочими штуками (хотя это уже исчезающе малый процент).
Определённо нужны, но не витринные. Витрина — это намного, намного хуже, чем даже использование OLED TV в качестве монитора
ИМХО, когда технология доходит до пика развития, она начинает развиваться в сторону украшательств и второстепенных фишечек. Кнопочные телефоны в конце своего пути пестрили разнообразием форм. Автомобили уже давно обрастают фишками и украшательствами, но принципиально не меняются.
И вот — смартфоны начинают петь свою лебединую песню разнообразием форм, чтобы потом уступить место AR‑устройствам
Скажем так. Оно умеет рисовать + вероятность нести дичь понижена
int* написать проще, чем std::shared_ptr<int>. Поэтому опасность удобнее и лаконичнее безопасности. Это проблема
Я рассуждаю следующим образом. Что мы могли бы сделать с языком, если наша задача предоставить сообществу разработчиков удобный, эффективный и безопасный инструмент?
Сломать обратную совместимость и сделать так, что int* — это и есть std::shared_ptr<int>, а для небезопасного указателя сделать std::unsafe_ptr<int>. Тогда получится, что безопасно писать удобнее, а небезопасно — неудобнее. Профит. Минус: мы тотально уничтожили обратную совместимость, да ещё и запутали разработчиков.
Сохранить обратную совместимость, но сделать так, что новый безопасный указатель проигрывает конкуренцию по эргономике небезопасному указателю - это то, что сделано сейчас. Вот это вот std::shared_ptr<int> - это неудобная дичь.
Сохранить обратную совместимость, но сделать так что новый указатель выигрывает конкуренцию по эргономике небезопасному указателю. Это будет стимулировать разработчиков использовать его. Это идеальный вариант. Проблема в том, что сложно придумать что-то лаконичнее, чем звёздочка *. Я понятия не имею, что это может быть.
Сохранить обратную совместимость, но сделать так что новый указатель не проигрывает конкуренцию по эргономике небезопасному указателю. Это не будет стимулировать разработчиков использовать его, но и не будет отталкивать. Как? Это уже дискусионный вопрос. Самое главное, что должно быть обязательно — эта форма не должна быть менее удобной, чем *. В рамках мозгового штурма можно накидать предлагаемые варианты:
int`
int@
int^ (занят C++ CLI)
int+
int$
int_ptr (добавление постфикса _ptr к любому типу делает его безопасным указателем)
Ничего не добавлять, но обязать встраивать в компилятор ИИ‑анализатор, который будет палить потенциальные неочевидные места, где int* выстрелит тебе в ногу и выкидывать варнинги — то, что сейчас кажется безумием, в будущем будет нормой.
Ещё что-нибудь, что не будет требовать писать жирные::__монструозные<констр>(укции) const.
Да, лезть в синтаксис с неочевидной фигнёй, наверное, не круто. А звёздочка — она разве очевидная? Она привычная, но не очевидная. Звёздочка есть часть синтаксиса, и она состоит из одного символа. Конкурировать по эргономике с ней может только то, что не сложнее. Поэтому, как бы неприятно это не было, это может быть только ещё один какой‑то символ. Да, это не так очевидно для тех, кто видит это в первый раз. Но C++ — это не про низкий порог вхождения, наверное. Хотя может я ошибаюсь.
Я не думаю, что моё предложение прям хорошее, и сам в нём не особо уверен, это просто размышления. Это субъективщина.
Обращаю внимание: утверждение о том, что текущая реализация плоха, и утверждение о том, как это, по моему субъективному мнению, можно было бы сделать лучше — это два разных утверждения. И даже если моё предложение неудачно — из ложности второго утверждения не следует ложность первого. Логика.
Мне часто приходится писать на C++, хотя да — это далеко не основной язык, которым я пользуюсь. В основном я хожу туда за числодробилками и/или 3D‑графикой.
Это частности, на примере которых я объясняю непродуманность и неудобность нововведений языка.
Я не говорю «частное владение нужно» или «частное владение не нужно», я не говорю «блокировки нужны» или «блокировки не нужны».
Я говорю, что в язык C++ блокировки были вставлены бездумно и неудобно, я говорю, что разделяемое владение было сделано бездумно и неудобно. И почти всё новое, что они туда засунули, они засунули бездумно и неудобно.
Ещё раз, само то, что засунули — хорошо, то каким именно способом засунули — плохо.
Вот и не хотят. Вот и не пишут. Вот и получается небезопасно. Об этом и речь. Надо чтобы вероятность захотеть написать безопасно была выше, чем вероятность захотеть написать небезопасно.
Более‑менее неплохой пример — то, как это сделано в C#. Я могу писать только безопасно. Если я хочу писать опасно, я сначала должен зайти, поставить галочку
потом написать
И только внутри мне позволят творить опасные опасности. А для
__makerefи__refvalueвообще не показываются автокомплиты. Небезопасному коду мешает и семантика языка, и компилятор языка, и среда разработки. А безопасный код пишется проще.А в C++ наоборот: если я хочу писать опасно, я просто пишу * и &. Если же я хочу писать безопасно, мне надо std::shared_ptr constexpr const const std::lock_guard.
Я не говорю что такой подход идеальный, просто в нём вектор удобства повернут в нужную сторону — удобнее писать безопасно, чем небезопасно.
Речь то не про конкретно приведение типов, а про то, что почти всё новое в C++ сделано неудобно. С каждым разом от тебя хотят всё больше и больше __всяких:::::::слов, <std::букв> и constexpr [[std::вырвиглазных]]:::<<<<конструкций___t>>> constexpr, апеллируя к Безопасности с большой красивой буквы std::Б.
Ниже unC0Rr привёл отличный пример:
Это что вообще за дичь? Зачем так делать? Зачем они пытаются догнать брейнфак? Им там скучно?
C++ хороший, не закапывайте C++, пожалуйста.