Самое смешное, я почему то уверен на 400% что код который он не смотрит все равно настроен и пишется агентами что учетом максимальной душноты его книг и статей.
Например, Яндекс на конференции Infrastructure’2026 сообщил о росте производительности внутри компании в 2-10 раз.
Т.е. они даже сами не знают во сколько? Толи в 2 толи в 10. А еще лучше было бы посмотреть то ли в 2 толи в 10 раз больше успешных продуктов которые они стали выпускать на рынок. Или успешный успех нельзя показывать?
Скорость ручного написания кода больше не является определяющей ценностью.
ну да ну да, где то встречал статистике что разработчик тратит 10–16% рабочего времени на написание кода, ценность куда деваться
При этом разработчик не имеет права быть ведомым нейросетями. Он сам должен корректировать ход работы, применяя свое видение.
Сами себе противоречите:
С приходом ИИ формируется новая роль — менеджер ИИ-агентов
Он же теперь не разработчик, откуда ему знать что там ИИ понаписали и откуда у него будет виденье, если он сам это писать не умеет?
Это сейчас разработчики по старой памяти это все знают и умеют а через какое то время не очень понятно откуда будут умельцы на дуде игрельцы которые как в старину и программировать будут уметь и за 5 агентами подглядывать и еще кофе варить начальству?
Человеку всегда тяжело даются перемены. Особенно сложно, когда он полностью погружен в свою работу и у него нет времени переосмыслить, как меняется отрасль. Задача руководителя — помочь разработчику сначала принять новые реалии, а затем адаптироваться к ним.
Особенно сложно, когда у него мамкины-руководители, которые при появлении нового инструмента пытаются не наладить улучшить а устроить революцию и все сломать.
Давайте будем честны. В последние 5 лет в IT пришло очень много случайных людей, которым все это айтишное совершенно не интересно, а вот деньги интересны. Все больше приходило некомпетентных менеджеров, которые подбирали себе не сильных технарей а удобный для себя людей, желательно софтскиловых гуманитариев. IT семимильными шагами, из более менее осмысленной, планируемой и ответственной деятельности, превращаеться в инфантильное и безответственное хайподр..чево, где одним плевать на все, лиж бы деньги платили, другие пришли в игры играть и за хайпом гоняться. В этом году модны микросервисы - перепишим все на них. В другом ФП - срочно нужно завести монадные трансформеры в проект. Все что угодно. Не важно что наступает ад, всем плохо а бизнес теряет деньги, главное чтобы игра в хайп продолжалась. К этому всему присовокупил определенный процент людей, которые когда то были норм, но сейчас у них семья рыбалки и вообще не до этого всего, просто платите деньги.
И тут на сцену выходит чудо-оружие, меч кладенец и палочка выручалочка в виде ИИ. Эффективные менеджеры в экстазе - наж же компании продающие ИИ пообещали повышение эффективности на 3000% да и можно поувольнять будет наконец то этих бездарей всех. Попаданцы и выгоревшие счастливы - теперь больше не нужно этим говном заниматься, печатай промты и занимайся своими делами. Хайпожоры счастливы - теперь можно хайпить на ИИ. И все плевать для чего это и можно ли этим пользоваться и в каких случаях.
И вот уже в одной статье - "Зачем писать код?", в другой "Я не писал код уже год и горжусь этим!", и уже в третьей "Зачем читать код?". Родилось сообщество ИИ наркоманов, которые уже давным давно все похоронили, для них мир давно изменился а они знать в новом мире. Причем чем меньше знают и больше полагаются на ИИ тем больше себя называют инженерами.
И вот IT в котором на серьезных проектах нужны были долгие согласование, где часто сидели и продумывали каждый шаг, сейчас дурдом.
Откуда должна появился мотивация у разработчика на развитие если он больше не пишет код? Зачем ему учить то что он ну будет писать? Если он не будет учиться то у него не будет квалификации а если не будет квалификации то как он будет проверять что сделал его любимый ИИ? Очевидно что никак. Но, who cares?
Это болото не из-за ИИ возникло, скорей обострило болезни современного IT комьюнити.
А автор учитывает что есть игры где нет 30000 сущностей и которые могут себе позволить писать нормальный код? А то прям вижу как оправдываясь этой статьей гкодеры и к goto придут, чо, сэкономит нам 1Е-250 секунды на сущность, хотя мы делаем визуальную новеллу
Напомните, а за чей счет они могут себя это позволить?
Вот есть пользователь, в интересах которого, игра или вообще любое ПО должно работать оптимально. В интересах пользователя чтобы программы мало занимали, быстро и хорошо работали. В интересах пользователя, программист должен используя свои знания и умения этого достичь. Но программисту это уже давно не интересно - он пишет для себя любимого а потом идет мирится своим чистым кодом с другими программистами, потому что срать хотел как этим будет пользователь пользоваться. Ему интересно паттерны внедрять, писать хороший код и любоваться им. Именно благодаря такой философии мы сейчас имеет кучу железа огромной мощности и бескрайние просторы говеного софта который есть память не в себя и постоянно тормозит.
Как Ваш выше уже писали:
Хорошая игра не та, что идеально сделана, а та в которую играют.
На втором месте наверное это всетаки качество игры для пользователя и уже только потом удобство для самого программиста.
Очень сложно объяснить в рамках коротких комментариев дух ООП специалисту, который вероятно не начинал программировать в мире без ООП, буквально в машинных кодах, когда ассемблер был роскошью (никаких макроассемблеров!). Похоже моя точка зрения практически получается диаметральной.
Из рассказовы вымышленного офицера: "Очень сложно объяснить военному , выступающему за гладкоствольные орудия, который вероятно не начинал воевать в мире без нарезных стволов. Буквально, с помощью бронзовых гладкоствольных пушек и ядер."
При всем уважении, не понимаю логику сравнения одного стиля программирования но с примерами из прошлого века с другим более современным, когда сейчас есть и ООП и процедурные и функциональные решения и сравнивать нужно их.
Компилятор понятия не имеет что у вас будет лежать в object и поэтому вынужден использовать наиболее обобщенный тип - ссылку размером 8 байт размещая данные в куче.
void P(T num) { } // размер неизвестен боксинга нет!
Так как T это дженерик а в C# дженерики специализируются то компилятору и не нужно знать T, вместо него будет конкретный тип с конкретным размером.
интерфейсу и object объект в куче, иначе виртуальные вызовы не работают. Вот struct и заворачивают
Вы не понимаете что просто не можете разместить struct находящийся за интерфейсом в стеке, потому что количество реализаций и следовательно размеров памяти которую потребуется выделить неопределенно?
Давайте на пальцах в том числе про виртуальные вызовы. Пример первый, с боксингом:
public interface IA {
int operation(int a, int b);
}
public record struct B(int X) : IA {
public int operation(int a, int b) {
return a + b + X;
}
}
public struct C : IA {
public int operation(int a, int b) {
return a * b;
}
}
public static int Fu(IA some, int a, int b) {
return some.operation(a, b);
}
В методе Fu будет боксинг. Потому что нельзя создать такую функцию Fu которая будет принимать первым параметром структуру любого размера. У нас в примере структура B имеет размер 4 байта а структура 0 байт. Поэтому компилятор вынужден приводить неизвестный размер к известному - ссылку в 8 байт. Затем действительно происходит виртуальный вызов.
Второй пример, без боксинга:
public static int Fu2<TA>(TA some, int a, int b) where TA : IA {
return some.operation(a, b);
}
Все тоже самое но боксинга нет. Потому что компилятор в данном случае сгенерирует два варианта функции Fu2, который будут выглядеть примерно так:
public static int Fu2B(B some, int a, int b) {
return some.operation(a, b);
}
public static int Fu2C(C some, int a, int b) {
return some.operation(a, b);
}
Никакой боксинг уже не нужен так как для каждого типа своя функция с известным размером. Никакие виртуальные вызовы тоже не нужны, потому как структура будет вызывать просто свой метод.
Вы можете спросить: а как же наследование без виртуальных функций? На что я отвечу что нет никакого наследования для struct. Если даже в интерфейсе будет дофлотная реализация метода а в структуре не будет ее реализации то вызов такого метода структуры будет просто прямым вызовом метода интерфейса.
Весь боксинг - это исключительно игра с размерами.
Но в ней есть одна небольшая неточность понимания или формулировки, усложняющая понимание этого механизма.
Боксинг — это когда struct нужно передать туда, где ждут ссылку на объект. Рантайм выделяет объект на куче и копирует туда значение структуры. Каждый боксинг — это аллокация, и ее видно в колонке Allocated у BenchmarkDotNet.
Вовсе не так. Нет никакой проблемы передать struct по ссылке. Проблема в другом - невозможно выделить на стеке struct, размер которого не знает компилятор. Это важное ограничение стека.
var list = new List<int> { 1, 2, 3 };
// Тип переменной - List<int>. foreach берет метод №1.
// Struct-энумератор живет на стеке. Аллокаций: 0.
foreach (var n in list) { }
public struct Enumerator : IEnumerator<T>, IEnumerator
{
private readonly List<T> _list;
private readonly int _version;
private int _index;
private T? _current;
...
}
Здесь конкретный struct размер которого понятен компилятору. Размер T будет определен для каждого конкретного типа, остальные размеры фиксированные. Можно выделять в стеке без проблем.
// Тип переменной - IEnumerable<int>. foreach берет метод №2.
// Тот же struct, но боксированный на кучу.
// Аллокаций: 1 объект на каждый foreach.
IEnumerable<int> seq = list;
foreach (var n in seq) { }
public interface IEnumerator<out T> : IDisposable, IEnumerator
where T : allows ref struct
{
new T Current
{
get;
}
}
А вот здесь уже, все что знает компилятор так это размер T. В остальное в зависимости от реализации может гулять. Нельзя формировать стек размер которого будут гулять.
Именно по этому, в данном случае, компилятор проводит боксинг т.е. делает из неизвестного размера struct известный - размер ссылки и решает эту проблему.
И это проклятье любого интерфейса за которым спрятан struct. Именно поэтому struct за дженериком ограниченный интерфейсом и не вызывает аллокаций а за интерфейсом вызывает.
Объект в ООП - это абстракция чуть выше памяти и операций ЦП. Например, при "функциональном программировании" тоже есть "объекты" - это совокупность функций, их параметров и их возвращаемых значений выстроенных в потоки выполнения.
Очень вольное обращение со словом объект. Да, и в ФП и в процедурном программировании можно упортреблять слово объект, но это структуры сгруппированных данных не более. Подход в этих парадигмах - есть отдельно функции а есть отдельно данные. Для ООП характерен стиль совмещения данных и функций, и хоть это тоже называется объектами, по смыслу это совсем иное чем объекты (структуры) из ФП и ПП.
Тут ничего нельзя сделать по другому - человек всё равно мыслит образами (т.е. объектами).
Не мыслит человек никакими объектами. В базовом виде все мышление всегда идет через описание применения алгоритмов над данными: - получить данные от клиента - провалидировать - послать запрос на обновление в БД - вернуть данные клиенту
Никаких объектов тут нет. Попытка смоделировать и натягивать объекты на реальный мир это куда более сложная и более высокая абстракция.
И хорошо, что появились языки программирования, предлагающие из коробки удачные способы объектного подхода.
Замечательно что они появились и что они были настолько удачные что несколько десятков лет все пытались писать на них нормально, да так успешно что в последнее время в новых языках отказываются от этой парадигмы как базовой.
"Чистый код" предполагает выбирать наиболее ясные и простые способы описать алгоритмы в .т.ч при помощи ООП, в первую очередь, чтобы другие люди могли его легко прочитать.
Ну и как, получилось? При помощи ООП и Чистый кода все стали писать понятный простой и чистый код?
ну не скажите, там например рассматривается задача как спроектировать редактор текста как типовая задача, это что задача конкретных людей? Есть кто-то кто не пользуется редактором текста? А если знать как правильно построить редактор текста, то можно использовать это знание чтобы построить редактор чего угодно. Там рассматривались фундаментальные задачи. С таким же успехом можно говорить что Нильс Бор, например, решал какие-то конкретно свои проблемы, а Эйнштейн написал
В книге знаний людей по конкретным темам в конкретный исторический период. У автором богатый опыт создания графических редакторов теста, поэтому про редактор и писали и про остальное, а не про фундаментальную философию разработки чего угодно. И паттерное 23 не потому что это 23 фундаментальных паттерна разработки вселенной а потому что это выборка из опыта конкретных людей в конкретное время. Этот опыт действительно очень обобщенный и может применяться в разных ситуация но это капля в море в мире проектирования различного софта.
Это я к чему, не к тому что оно плохое а к тому что люди воспринимают это как библио которая даст ответ на все вопросы. Не даст.
Кстати, применение ООП, по моему опыту, резко уменьшает производительность. Везде ли стоит его применять? Вот вопрос...
Я пришел к тому ООП это очень местечковая история, и главная проблема - это пыпытка на нем делать все. Из того где это может быть полезно это оборачивание ресурса для управления его жизненным циклом и небольшие стейт-машины на уровне кода, где состояние не выходит за пределы объекта.
Мне кажеться что проблема ООП не только в производительности но и в самой чужеродности подхода попытки все представить объектами при исполнении программы.
Просто не надо воспринимать прочитанное как догму.
Проблема в том что большинство думать не хотят но хотят воспринимать все проще, как догму и будут так воспринимать. Поэтому мы и наблюдаем как сообщество десятки лет безуспешно пытается научиться пользоваться ООП, веря что ну должно же оно все проблемы решить. Потом паттерны GOF, которые не более чем набор советов конкретных людей о конкретно их проблемах, в конкретный момент времени, стали культом. Потом Clean code. Потом пришло безумие повального функционального программирования. Затем микросервисы. Потом DDD-шиза.
Потому что много думать - много грустный. Все хотят чудо решение.
Проблема в том что большинство программистов, последнее время пафосно направо и налево называющих себя инженерами, никакого отношения ни к понятию инженерного дела ни к понятию прагматизма не имеют. Уже давным давно балом правит хайп.
По хорошему, человек который прочитал Clean Code и думающий его внедрять, должен задаться вопросами: а кто такой автор книги и какой у него опыт и можно ли посмотреть его проекты, а если ли доказательства эффективности предлагаемых им методик, наконец провести мозговой штурм с коллегами проверяя это все на прочность. И тогда неожиданно выясниться что Мартин - обычный хайпожор, завирусившийся на книгах и статья без каких либо серьезных достижений, серьезные работы которого особо негде посмотреть. Ну т.е. типичный советчик. Далее, каких нибудь ну хоть сколько то объективных доказательств просто нет. А многие его советы не выдерживают критики. Но так должны думать нормальные инженеры, а для большинства нужен вайб и хайп. Clean Code модный - значит будем его внедрять. Это касается не только данной темы.
Удивляет только что такой хренью начали страдать в геймдеве. В энтерпрайзе то это все расцвело потому что так программист мало за что отвечает. Будет тормозить не вывозить - это проблема заказчика, пусть серверов докупает. А мы художники, мы высокими архитектурами занимается по книжками.
Может ли магистратура сделать из разработчика мидл-специалиста
Можем ли мы говорить, что после онлайн-магистратуры студенты станут мидлами? Конечно, обещать такое мы не можем. Даём ли мы знания, которым должен обладать мидл-специалист? Да, даём. Но очень многое зависит от самого студента: его мотивации, желания выделять время на учёбу и проекты. Мидл — это не только про формально пройденный материал, это ещё и про опыт и уровень самостоятельности специалиста.
Может ли студент закончивший медицинскую академию сразу идти оперировать людей? Может ли студент закончивший строительный ВУЗ сразу пойти проектировать дома? А если курсы специальные пройти? Думаю ответ очевиден. А программист конечно же сразу станет мидлом если ему секретные знания расскажут?
Для того чтобы стать условным мидлом, нужно уже быть джуном хотя бы год-полтора. Уже иметь устоявшиеся джуновские знания и опыт, уже набить все необходимые шишки. Чтобы двигаться на новый уровень нужен фундамент старого.
Все рассказы про то что можно сразу перепрыгнуть позицию не более чем реклама курсов.
А в Java при добавлении generic-ов решили не ломать совместимость и не плодить коллекций, а раз уж всё равно боксить, то нафиг value types?
Не совсем так. Они пробовали сделать поддержку специализированных дженериков но не смогли достичь ощутимых результатов, поэтому остановились на боксинге. На эту тему есть целая статья Одерски как они это делали.
просто размышляю о том, почему некоторые выгодные во всех смыслах решения в свое время не были переосмыслены и скопированы
Потому что это решение не выгодно именно "во всех смыслах". У Java и C# разная философия, нет большого смысла из Java делать второй C#.
Java проще на начинающих, в ней сильно сложнее отстрелить себе ноги - это ее основная философия с самого начала. Если бы добавили struct то язык стал бы сильно сложнее, а потом вместе in, out, ref, span и понеслось. Плюс, есть многие вещи в JVM которые принципиально плохо совместимы с этим. На вскидку не скажу но там и на GC завязано и в целом на всю спецификацию.
Но основной посыл что не было смысла делать клон C# с большим количеством детских болезней.
Да, помню я эти времена, когда особой популярностью пользовались ассемблерные вставки ровно под тот же речитатив про "контроль, я могу управлять, мне виднее" и все такое. И как потом полыхало так, что зарево было видно за километры, когда оказалось, что компилятор давным-давно все это делает куда лучше и оптимальнее. Так и тут - это не контроль, а видимость контроля, который в среднем по больнице никогда не будет оправдан. Так что лично я могу только приветствовать, что джава не грузит меня этим самым контролем, а тихонько под капотом делает свое дело.
Вопрос исключительно - для чего.
Java/JVM сейчас это на 99% backend приложения и заточена на среднего специалиста, с философией - разработчику доверять нельзя, он может отстрелить себе ноги, поэтому все запретим и из кожи вон будем вылезать компенсируя свои запреты, чтобы закрыть проблемы производительности, памяти и безопасности пассивно. Для backend приложений - это более чем оправдано.
C#/.Net это инструмент практически для любых задач и вообще другая история вида - мы все взрослые люди, мы можем писать и на высоком уровне но у нас в кладовке есть все инструменты для специалистов с прямыми руками и мы не боимся ими пользоваться
Все эти разговоры про:
компилятор давным-давно все это делает куда лучше и оптимальнее
это не контроль, а видимость контроля, который в среднем по больнице никогда не будет оправдан
они от избалованности написанием современных приложений где можно класть на производительность и расход памяти. Как только появляются какие-то требования к производительности никто в здравом уме не будет полагаться на blackbox, что-там на уме у компилятора в этом релизе, на каком тире что-то будет оптимизировано и молиться на то чтобы все само оптимизировалось.
Как только struct присваивается переменной интерфейсного типа, он боксится — ведь интерфейс ссылочный. Вызов s.Area() идёт уже по упакованной копии. Если вы держите Circle в локальной переменной конкретного типа и вызываете Area() напрямую — боксинга нет. Грабли вылезают, когда struct “прячут” за интерфейс ради полиморфизма.
Лечение: generic-ограничение where T : struct, IShape вместо переменной интерфейса — JIT специализирует код по value-типу и вызывает метод без упаковки.
Ссылочность вообще не причем. Структуры прекрасно передаются по ссылке без всяких аллокаций. Проблема в том что каждая передаваемая переменная должна иметь фиксированный заранее известный размер. Если переменная интерфейсного типа то размер фактически передаваемых данных может быть любым до 0 и далее. Не может быть переменной или параметра, размер которого никто не знает при исполнении. В отличии от ссылки размер которой всегда фиксированный. Боксинг это способ впихнуть невпихуемое.
Когда мы пишем ограничение where T : struct, IShape то это совсем другая история, так как это скрывает вызов отдельной предварительно сгенерированной функции для каждого используемого типа. У каждой функции будет свой параметр фиксированного размера.
Боксинг, который уже НЕ боксит: чему научился рантайм
Generic-методы со struct-аргументом не боксят сам аргумент.EqualityComparer<T>.Default, List<T>, Dictionary<TKey,TValue> специализируются по value-типу: JIT генерирует отдельный нативный код на каждый struct-аргумент, и упаковки value→object там нет (при условии корректного IEquatable<T> — см. пункт 3).
Что значит уже? В C# изначально мономорфизация параметров типов что значит что любой вариант типа с параметром мономорфизируеться в отдельный тип, там нечему бокситься и незачем. Другими словами, не было никакого List<int> всегда был List_int.
Самое смешное, я почему то уверен на 400% что код который он не смотрит все равно настроен и пишется агентами что учетом максимальной душноты его книг и статей.
Т.е. они даже сами не знают во сколько? Толи в 2 толи в 10. А еще лучше было бы посмотреть то ли в 2 толи в 10 раз больше успешных продуктов которые они стали выпускать на рынок. Или успешный успех нельзя показывать?
ну да ну да, где то встречал статистике что разработчик тратит 10–16% рабочего времени на написание кода, ценность куда деваться
Сами себе противоречите:
Он же теперь не разработчик, откуда ему знать что там ИИ понаписали и откуда у него будет виденье, если он сам это писать не умеет?
Это сейчас разработчики по старой памяти это все знают и умеют а через какое то время не очень понятно откуда будут умельцы на дуде игрельцы которые как в старину и программировать будут уметь и за 5 агентами подглядывать и еще кофе варить начальству?
Особенно сложно, когда у него мамкины-руководители, которые при появлении нового инструмента пытаются не наладить улучшить а устроить революцию и все сломать.
Я думаю человечеству будет только на пользу что
горшочек перестал варитьдедушка перестал писать код.Давайте будем честны. В последние 5 лет в IT пришло очень много случайных людей, которым все это айтишное совершенно не интересно, а вот деньги интересны. Все больше приходило некомпетентных менеджеров, которые подбирали себе не сильных технарей а удобный для себя людей, желательно софтскиловых гуманитариев. IT семимильными шагами, из более менее осмысленной, планируемой и ответственной деятельности, превращаеться в инфантильное и безответственное хайподр..чево, где одним плевать на все, лиж бы деньги платили, другие пришли в игры играть и за хайпом гоняться. В этом году модны микросервисы - перепишим все на них. В другом ФП - срочно нужно завести монадные трансформеры в проект. Все что угодно. Не важно что наступает ад, всем плохо а бизнес теряет деньги, главное чтобы игра в хайп продолжалась. К этому всему присовокупил определенный процент людей, которые когда то были норм, но сейчас у них семья рыбалки и вообще не до этого всего, просто платите деньги.
И тут на сцену выходит чудо-оружие, меч кладенец и палочка выручалочка в виде ИИ. Эффективные менеджеры в экстазе - наж же компании продающие ИИ пообещали повышение эффективности на 3000% да и можно поувольнять будет наконец то этих бездарей всех. Попаданцы и выгоревшие счастливы - теперь больше не нужно этим говном заниматься, печатай промты и занимайся своими делами. Хайпожоры счастливы - теперь можно хайпить на ИИ. И все плевать для чего это и можно ли этим пользоваться и в каких случаях.
И вот уже в одной статье - "Зачем писать код?", в другой "Я не писал код уже год и горжусь этим!", и уже в третьей "Зачем читать код?". Родилось сообщество ИИ наркоманов, которые уже давным давно все похоронили, для них мир давно изменился а они знать в новом мире. Причем чем меньше знают и больше полагаются на ИИ тем больше себя называют инженерами.
И вот IT в котором на серьезных проектах нужны были долгие согласование, где часто сидели и продумывали каждый шаг, сейчас дурдом.
Откуда должна появился мотивация у разработчика на развитие если он больше не пишет код? Зачем ему учить то что он ну будет писать? Если он не будет учиться то у него не будет квалификации а если не будет квалификации то как он будет проверять что сделал его любимый ИИ? Очевидно что никак. Но, who cares?
Это болото не из-за ИИ возникло, скорей обострило болезни современного IT комьюнити.
Напомните, а за чей счет они могут себя это позволить?
Вот есть пользователь, в интересах которого, игра или вообще любое ПО должно работать оптимально. В интересах пользователя чтобы программы мало занимали, быстро и хорошо работали. В интересах пользователя, программист должен используя свои знания и умения этого достичь. Но программисту это уже давно не интересно - он пишет для себя любимого а потом идет мирится своим чистым кодом с другими программистами, потому что срать хотел как этим будет пользователь пользоваться. Ему интересно паттерны внедрять, писать хороший код и любоваться им. Именно благодаря такой философии мы сейчас имеет кучу железа огромной мощности и бескрайние просторы говеного софта который есть память не в себя и постоянно тормозит.
Как Ваш выше уже писали:
На втором месте наверное это всетаки качество игры для пользователя и уже только потом удобство для самого программиста.
Из рассказовы вымышленного офицера: "Очень сложно объяснить военному , выступающему за гладкоствольные орудия, который вероятно не начинал воевать в мире без нарезных стволов. Буквально, с помощью бронзовых гладкоствольных пушек и ядер."
При всем уважении, не понимаю логику сравнения одного стиля программирования но с примерами из прошлого века с другим более современным, когда сейчас есть и ООП и процедурные и функциональные решения и сравнивать нужно их.
Окей. Какого размера
sharpobject? Наверное это int размером 4? Точно? А если так?Или так?
А если так?
Компилятор понятия не имеет что у вас будет лежать в object и поэтому вынужден использовать наиболее обобщенный тип - ссылку размером 8 байт размещая данные в куче.
Так как
Tэто дженерик а в C# дженерики специализируются то компилятору и не нужно знатьT, вместо него будет конкретный тип с конкретным размером.Вы не понимаете что просто не можете разместить struct находящийся за интерфейсом в стеке, потому что количество реализаций и следовательно размеров памяти которую потребуется выделить неопределенно?
Давайте на пальцах в том числе про виртуальные вызовы. Пример первый, с боксингом:
В методе
Fuбудет боксинг. Потому что нельзя создать такую функциюFuкоторая будет принимать первым параметром структуру любого размера. У нас в примере структураBимеет размер 4 байта а структура 0 байт. Поэтому компилятор вынужден приводить неизвестный размер к известному - ссылку в 8 байт. Затем действительно происходит виртуальный вызов.Второй пример, без боксинга:
Все тоже самое но боксинга нет. Потому что компилятор в данном случае сгенерирует два варианта функции
Fu2, который будут выглядеть примерно так:Никакой боксинг уже не нужен так как для каждого типа своя функция с известным размером. Никакие виртуальные вызовы тоже не нужны, потому как структура будет вызывать просто свой метод.
Вы можете спросить: а как же наследование без виртуальных функций? На что я отвечу что нет никакого наследования для struct. Если даже в интерфейсе будет дофлотная реализация метода а в структуре не будет ее реализации то вызов такого метода структуры будет просто прямым вызовом метода интерфейса.
Весь боксинг - это исключительно игра с размерами.
Спасибо за статью!
Но в ней есть одна небольшая неточность понимания или формулировки, усложняющая понимание этого механизма.
Вовсе не так. Нет никакой проблемы передать struct по ссылке. Проблема в другом - невозможно выделить на стеке struct, размер которого не знает компилятор. Это важное ограничение стека.
Здесь конкретный struct размер которого понятен компилятору. Размер
Tбудет определен для каждого конкретного типа, остальные размеры фиксированные. Можно выделять в стеке без проблем.А вот здесь уже, все что знает компилятор так это размер
T. В остальное в зависимости от реализации может гулять. Нельзя формировать стек размер которого будут гулять.Именно по этому, в данном случае, компилятор проводит боксинг т.е. делает из неизвестного размера struct известный - размер ссылки и решает эту проблему.
И это проклятье любого интерфейса за которым спрятан struct. Именно поэтому struct за дженериком ограниченный интерфейсом и не вызывает аллокаций а за интерфейсом вызывает.
Очень вольное обращение со словом объект. Да, и в ФП и в процедурном программировании можно упортреблять слово объект, но это структуры сгруппированных данных не более. Подход в этих парадигмах - есть отдельно функции а есть отдельно данные. Для ООП характерен стиль совмещения данных и функций, и хоть это тоже называется объектами, по смыслу это совсем иное чем объекты (структуры) из ФП и ПП.
Не мыслит человек никакими объектами. В базовом виде все мышление всегда идет через описание применения алгоритмов над данными:
- получить данные от клиента
- провалидировать
- послать запрос на обновление в БД
- вернуть данные клиенту
Никаких объектов тут нет. Попытка смоделировать и натягивать объекты на реальный мир это куда более сложная и более высокая абстракция.
Замечательно что они появились и что они были настолько удачные что несколько десятков лет все пытались писать на них нормально, да так успешно что в последнее время в новых языках отказываются от этой парадигмы как базовой.
Ну и как, получилось? При помощи ООП и Чистый кода все стали писать понятный простой и чистый код?
В книге знаний людей по конкретным темам в конкретный исторический период. У автором богатый опыт создания графических редакторов теста, поэтому про редактор и писали и про остальное, а не про фундаментальную философию разработки чего угодно. И паттерное 23 не потому что это 23 фундаментальных паттерна разработки вселенной а потому что это выборка из опыта конкретных людей в конкретное время. Этот опыт действительно очень обобщенный и может применяться в разных ситуация но это капля в море в мире проектирования различного софта.
Это я к чему, не к тому что оно плохое а к тому что люди воспринимают это как библио которая даст ответ на все вопросы. Не даст.
Я пришел к тому ООП это очень местечковая история, и главная проблема - это пыпытка на нем делать все. Из того где это может быть полезно это оборачивание ресурса для управления его жизненным циклом и небольшие стейт-машины на уровне кода, где состояние не выходит за пределы объекта.
Мне кажеться что проблема ООП не только в производительности но и в самой чужеродности подхода попытки все представить объектами при исполнении программы.
Проблема в том что большинство думать не хотят но хотят воспринимать все проще, как догму и будут так воспринимать. Поэтому мы и наблюдаем как сообщество десятки лет безуспешно пытается научиться пользоваться ООП, веря что ну должно же оно все проблемы решить. Потом паттерны GOF, которые не более чем набор советов конкретных людей о конкретно их проблемах, в конкретный момент времени, стали культом. Потом Clean code. Потом пришло безумие повального функционального программирования. Затем микросервисы. Потом DDD-шиза.
Потому что много думать - много грустный. Все хотят чудо решение.
Проблема в том что большинство программистов, последнее время пафосно направо и налево называющих себя инженерами, никакого отношения ни к понятию инженерного дела ни к понятию прагматизма не имеют. Уже давным давно балом правит хайп.
По хорошему, человек который прочитал Clean Code и думающий его внедрять, должен задаться вопросами: а кто такой автор книги и какой у него опыт и можно ли посмотреть его проекты, а если ли доказательства эффективности предлагаемых им методик, наконец провести мозговой штурм с коллегами проверяя это все на прочность. И тогда неожиданно выясниться что Мартин - обычный хайпожор, завирусившийся на книгах и статья без каких либо серьезных достижений, серьезные работы которого особо негде посмотреть. Ну т.е. типичный советчик. Далее, каких нибудь ну хоть сколько то объективных доказательств просто нет. А многие его советы не выдерживают критики. Но так должны думать нормальные инженеры, а для большинства нужен вайб и хайп. Clean Code модный - значит будем его внедрять. Это касается не только данной темы.
Удивляет только что такой хренью начали страдать в геймдеве. В энтерпрайзе то это все расцвело потому что так программист мало за что отвечает. Будет тормозить не вывозить - это проблема заказчика, пусть серверов докупает. А мы художники, мы высокими архитектурами занимается по книжками.
Уточню на всякий случай, речь идет о проектах связанных с ML и подобным или вообще о всех существующих типах проектов?
Я правильно понимаю, с Ваших слов,что приложение на python можно написать быстрее чем на Go в 10 раз?
Может ли студент закончивший медицинскую академию сразу идти оперировать людей?
Может ли студент закончивший строительный ВУЗ сразу пойти проектировать дома?
А если курсы специальные пройти?
Думаю ответ очевиден.
А программист конечно же сразу станет мидлом если ему секретные знания расскажут?
Для того чтобы стать условным мидлом, нужно уже быть джуном хотя бы год-полтора. Уже иметь устоявшиеся джуновские знания и опыт, уже набить все необходимые шишки. Чтобы двигаться на новый уровень нужен фундамент старого.
Все рассказы про то что можно сразу перепрыгнуть позицию не более чем реклама курсов.
Не совсем так. Они пробовали сделать поддержку специализированных дженериков но не смогли достичь ощутимых результатов, поэтому остановились на боксинге. На эту тему есть целая статья Одерски как они это делали.
Потому что это решение не выгодно именно "во всех смыслах". У Java и C# разная философия, нет большого смысла из Java делать второй C#.
Java проще на начинающих, в ней сильно сложнее отстрелить себе ноги - это ее основная философия с самого начала. Если бы добавили struct то язык стал бы сильно сложнее, а потом вместе in, out, ref, span и понеслось. Плюс, есть многие вещи в JVM которые принципиально плохо совместимы с этим. На вскидку не скажу но там и на GC завязано и в целом на всю спецификацию.
Но основной посыл что не было смысла делать клон C# с большим количеством детских болезней.
Вопрос исключительно - для чего.
Java/JVM сейчас это на 99% backend приложения и заточена на среднего специалиста, с философией - разработчику доверять нельзя, он может отстрелить себе ноги, поэтому все запретим и из кожи вон будем вылезать компенсируя свои запреты, чтобы закрыть проблемы производительности, памяти и безопасности пассивно. Для backend приложений - это более чем оправдано.
C#/.Net это инструмент практически для любых задач и вообще другая история вида - мы все взрослые люди, мы можем писать и на высоком уровне но у нас в кладовке есть все инструменты для специалистов с прямыми руками и мы не боимся ими пользоваться
Все эти разговоры про:
они от избалованности написанием современных приложений где можно класть на производительность и расход памяти. Как только появляются какие-то требования к производительности никто в здравом уме не будет полагаться на blackbox, что-там на уме у компилятора в этом релизе, на каком тире что-то будет оптимизировано и молиться на то чтобы все само оптимизировалось.
Каждый инструмент под свои задачи.
Ссылочность вообще не причем. Структуры прекрасно передаются по ссылке без всяких аллокаций. Проблема в том что каждая передаваемая переменная должна иметь фиксированный заранее известный размер. Если переменная интерфейсного типа то размер фактически передаваемых данных может быть любым до 0 и далее. Не может быть переменной или параметра, размер которого никто не знает при исполнении. В отличии от ссылки размер которой всегда фиксированный. Боксинг это способ впихнуть невпихуемое.
Когда мы пишем ограничение
where T : struct, IShapeто это совсем другая история, так как это скрывает вызов отдельной предварительно сгенерированной функции для каждого используемого типа. У каждой функции будет свой параметр фиксированного размера.Что значит уже? В C# изначально мономорфизация параметров типов что значит что любой вариант типа с параметром мономорфизируеться в отдельный тип, там нечему бокситься и незачем. Другими словами, не было никакого
List<int>всегда был List_int.