Труд не трудится
Компилятор не компилится

Боброе утро, сегодня прекрасный день

Мое мнение по поводу вайб кодинга и использования ИИ в коде [1/2]

(Спойлер - хорошее)

Будем честны: Компьютер - пиздец какая сложная штука. В нем находится несколько миллиардов байт (1 ГБ = 1 млрд. байт, а у вас наверняка 16 ГБ ОЗУ и несколько терабайт жёсткого диска...). И становится сложно каждый такой байт оцифровывать. Для этого придумали "слои упрощения", которые со временем эволюционировали. Но начнем с начала:

Assembler - прямое общение с железом. Вроде бы не плохо, но при увеличении размерности становится сложно... Человек подумал, подумал, да придумал:

Компиляторы - специальная программа, которая переводит более менее понятные человеку код в ассемблерные инструкции (машинный код). Примерами можно привести С/С++. Но планка входа в них довольно таки высокая, да и логирование ошибок довольно все же муторное, поэтому появились они:

Интерпретаторы - программа, которая в реальном времени переводит человеческий код в машинный и/или вызывает уже скомпилированные функции внутри программы. Например Python для Blender/Unreal или Lua для Garry's Mod. Интерпретируемые языки более просты, легко логируемые и очень хорошо опускают планку входа. Но что действительно сильно опустило планку:

Blueprints - вообще, правильно сказать "визуальное программирование", но суть уловили. Это очень мощная вещь, которая сильно отличается своей простотой и понятностью. Ни одной строчки кода. Собрал цепочку из нод, нажал кнопочку "скомпилировать" и уже движок под капотом из нод собирает С++ код, а С++ код в свою очередь компилируется в машинный код. То есть Blueprints -> C++ -> Assembler.

И можно заметить: Каждый следующий слой автоматизирует и упрощает работу с предыдущим, это в своем роде превращается в "интерфейс к интерфейсу". И уже нужно сказать стоп! Мы и так опустили планку! Но нет... Долгое время для того чтобы влиться в кодинг нужно было понимать хотя бы базовые концепции и синтаксис (область определения, или хотя бы отличать int от float ¯\_(ツ)_/¯), а затем появились они:

ИИ-Ассистенты - ChatGPT, Copilot, DeepSeek, Perplexity и другие... Искусственный интеллект не только опустил планку входа в кодинг до минимума, но также автоматизировал то, что раньше было нормой. И я даже не про написание шаблонного кода. Теперь рефакторинг, написание документации и более четкое прописывание архитектуры стало чем-то в своем роде живописью. Разработчики превратились из строителей в архитекторов. Хочу сказать, что мы живём в хорошее время.. Однако...

У этого и других слоев есть свои особенности. В один пост все не уместить, так что в следующей части расскажу про подводные камни и свое финальное мнение по этой теме

Мое мнение по поводу вайб кодинга и использования ИИ в коде [2/2]

(Завершим начатое)

В прошлом посту рассказал про своеобразные "слои автоматизации", которые покрывают слои ниже, упрощают разработку и опускают планку входа в кодинг. Но какие подводные камни могут быть?

Понимание - основная концепция программирования. Понимание как работает память, вычисление, стек, чтение/запись, как процессор взаимодействует с видеокартой, оперативной памятью, кэшом и многое другое. Безусловно это безумие можно и не знать и спать спокойно.

Простой пример: Водителей можно разделить на 2 типа. Одни просто давят педаль газа, сцепления, не понимая что они делают. А другие уже более осознанно совершают свои действия, понимают как работает автомобиль и умеют за ним ухаживать

Или ближе к нашей теме: Приведу пример нашего UI Дизайнера At0m. В Девлоге 4 по Портал Солверу он рассказал и показал, что подгружать текстуру для каждого элемента затратнее, чем использовать материалы и параметры. С одной стороны ничего не поменялось, но! Оптимизация выросла (прям очень). Такое глубокое осознание, как работает подгрузка, как взаимодействует процессор и тд. еще раз подчеркивает его опыт и доказывает саму суть программирования - понимание

И также солидарен с еще одним комментатором, ведь я тоже был таким - еще 1.5 года назад, после выхода Демо, я не был опытен ни в плюсах, ни в Анриле (максимум в Ардуино). Но была мотивация от:
1 - Ожидания сообщества продолжения проекта
2 - Большая вина за ту оптимизацию, что я собственно говоря... допустил

И да, Искусственный Интеллект в первые 3 месяца очень активно помогал мне, затем еще 3 месяцев я +- делал все сам, при это каждый раз с ИИ изучал новые идеи и возможности движка, и в конце концов перед 1.1.0 переписал бекенд, убрал большую часть мусора из моего старого кода и сильно оптимизировал критические части

Дошло даже до того, что последние 3 дня на опыте изучил конструкторы, CDO (Class Default Object) и даже получил звездюлей от использования GEngine там где не надо было ;)

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

И будем честны - Заменяют разработчиков не ИИ, а начальники, которые думают что ИИ дешевле и умнее. Он дешевый, он умный, но он нифига не опытный

А отвечая на вопрос про вайб-кодинг:
Да, вайб-кодинг - следующий этап в эволюции кодинга. Это был ожидаемый этап также, как изобретение компиляторов или визуального программирования. Это было предначертано, и мы это получили, но... Будьте на стороне прогрессивного вайб-кодинга. Используйте инструменты по назначению и не делайте из себя оператора кода, который только, как обезьяна, копипастит код. Увидели новую конструкцию? Спросите что это. Не понимаете? Спросите как это работает. В конце концов так и появляются знания :D

Я рад, что появился ИИ (даже в мои времена 2016-2022 с StackOverFlow о таком только можно было мечтать). Но я крайне не согласен с людьми, которые полностью доверяют ИИ. Будьте рациональнее, держите ситуацию в своих руках. ИИ пришел, ИИ уйдет, а на вас - ответственность

Be Rational. Think Cold

Короткая, но хорошая статья про вайб-кодинг

Суть в том, что вайб-кодинг конечно хорош в своем плане, но для качественного проекта лучше сразу строить с профессионалами, чтобы потом не переписывать/перестраивать все заново (в аналогию приведены времена 80х-90х)

Хабр: https://habr.com/ru/articles/951282/

Угу-угу, никого ничто не смущает?

Вспомнил капкат и решил смонтажить что-то (спасибо RootTool за перевод)

Емае, мой перевод хоть где-то пригодился :3
Тогда в ответку.. Предлагаю поддержать человечка:

https://youtu.be/W9_GpA7EvWU?si=z2u0dJVizruWSRUB

❤️ - Visual Studio Code
🔥 - Rider IDE
👀 - notepad.exe

Скоро уже 20 лет....

Доброе утро

Выравнивание данных (Data Alignment) в C++
#новичкам

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

Начнем с основы: Стек - Область оперативной памяти, в которой хранятся временные переменные во время работы вашей программы. Процессор подгружает эти переменные из стека в свой кеш и работает с ними (производит какие-либо операции и тд.)
P.S. Я знаю, обьяснено крайне поверхностно, не бейте

Но стек подгружается в кеш блоками, то есть, за 1 такт считывает определенную область с стека в кеш и работает с ней. Обычно оно кратно 4/8/16/32/64 (Зависит от архитектуры процессора и настроек компилятора) и тема "Выравнивание данных" как раз про это

В теории: Для правильной подгрузки компиляторы обычно выравнивают данные структур под четкую размерность (MSVC: 8 байт для x64 и 4 байт для x32) чтобы не было долгой подгрузки частями (что замедляет работу и может привести к исключениям-). И именно тут все зависит от программиста, ведь правильное размещение полей структуры напрямую влияет на производительность и корректность программы (оптимизация ура)

На практике: Рассмотрим структуры FGoodStructure и FBadStructure. Обе имеют одинаковое количество информации, по идее и размер (8+4+2+1 = 15 байт) должен быть одинаковым, так? Не совсем: Узнав размер структуры через функцию sizeof() выяснится неприятная новость - FBadStructure имеет размер 24 байт, в то время как FGoodStructure только 16

Почему так? Ответ в выравнивании - процессору удобно обращаться к определенному типу данных по адресу, кратному 4 (или 8). И в данном случае в FBadStructure имеет плохое расположение полей - int SomeInt (4 байт) попросту не уместить рядом с char SomeChar (1 байт) - компилятору НУЖНО вставить 3 пустых байта между ними для выравнивания. И да, это фича, с вытекающими ввиде раздутого размера структуры

А для лучшего понимания давайте лучше визуализируем (и нет, это не придумано мною, буквально программа сама выдает этот результат). Как видите между SomeInt и SomeChar стоит 3 байта для выравнивания, а после SomeNumber аж 6 пустых байт. Безумие? Ага. Но зато какое. При этом у FGoodStructure реально все хорошо. Всего-лишь 1 пустой байт для выравнивания размера к кратному 8 (в данном случае размер 15 байт ближе к 16 вместо 24 :D)

Смысл басни такова: Прописывайте свои поля в структуре так, чтобы размеры их типов шли от большего к меньшему (как в примере FGoodStructure). Это легко, это просто, это эффективно. Программу не сломает, а процессор спасибо скажет

Aligment Your Structures. Think Cold.