Холивары вокруг C++

@Alex TROCKII · Регистрация: 18.08.2017

Студворк — интернет-сервис помощи студентам

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

На этом форуме живет один мой очень древний знакомый Андрээ С, который здесь точно и однозначно был админом. когда то давно он даже активно пытался меня банить, когда я любил немного пошалить и потролить кодеров. Так вот, прошло лет 10, а наша основная тема спора оказывается до сих пор актуальна. Спор у меня недавно возник с другим кодером, потому с Андрэ Мандрэ мы очень давно не общались. Суть спора можно объяснить одной его фразой: "С# это кастрированный с++". ну типа существует язык цпп для реальных программистов, а си шарп это какая та дичь не понятно для кого вообще и не понятно зачем.

Дело в том, что я даже поверил этому и начал один из своих проектов кодить на цпп. Ну думал такой, что щас подтяну знания реально крутого языка, на котором написаны почти все крупные проекты. ФИГ!
Я не помню точно на чем я забуксовал, но точно помню финальную мысль - это кал вонючий, на котором нету вообще никаких удобств, траблы с библиотеками (может быть сейчас не актуально уже) и вообще как работать с объектами когда всё настолько хреново.

вот простые моменты, от которых жопа сразу сгорает мгновенно:
1. статические массивы. если мне надо добавить что-то в середине массива, то это танцы с бубном с пересозданием.
2. надо следить за памятью и чистить все неиспользуемые переменные, ибо память бесконтрольно засирается
3. отсутствие таких коллекций как List<T>, ObservableCollection, dictionary и тд... просто без комментариев
4. отсутсвие linq
n. примитивная низкоуровневость

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

в си шарпе у меня объекты на объектах, они крупные и каждый класс насыщен большим количеством логики. я просто не представляю сколько времени мне бы пришлось убить на возню в с++, это просто страшно.
я понимаю конечно, что как бы "СКОРОСТЬ РАБОТЫ РЕШАЕТ!", что софт на шарпе по определению работает медленнее потому что управляемый код и тд... но всему своё место. я не майнер пишу, который должен быть оптимизирован по максимуму.
есть смысл всю логику перегонять на быстрые языки, если это игровой движок - ну там чем быстрее код работает, тем больше объектов отрисовывает, тут как бы ок. есть смысл нанять толпу батанов из вычислительного центра НАСА, чтобы кодили 24/7 каждую мелочь на цпп и гнались за каждой выйгранной миллисекундой, вполне возможно это действительно оправдано.

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

@Ludwig Valentin · 12.06.2024, 00:29

Сообщение от COKPOWEHEU

То есть не ознакомились... Это принципиально другой подход к программированию, не тот, к которому вы привыкли

Знаю, что Лисп оперирует списками.
Но напишите процедуру или функцию на Си или на Паскале.

@ft4l · 12.06.2024, 01:31

Сообщение от Ludwig Valentin

на Си

функциональный но насколько-то и процедурный подход

C
1
2
3
4
DWORD WINAPI CtrlC(void* x){
    GenerateConsoleCtrlEvent(CTRL_C_EVENT, 0);
    return 0;
}

процедурный

C
1
2
3
4
5
void show_commands(void){
    register USHORT i;
    for(i=0; i<g_CMD_Count; ++i)
        RE_mesg( MSG_cmd_showall    |TXTC_INF|BGC_INF, (*g_CMD)[i].Type, (*g_CMD)[i].Cmd);
}

... что-то из файла первых моих программок )
Вторая подпрограмма юзает глобальный массив g_CMD[g_CMD_Count] и с ним работает куча других подпрограмм
Первую можно было-бы тоже сделать void (void ) но там было типа dw = CreateRemoteThread(SD->hProc,0,0,&CtrlC,0,0,0)
но всё оно почему-то потом у меня всё позакомментировалось.)

... с Perl всё понятнее )) функции только то что в ядре ... всё остальное подпрограммы и модули с подпрограммами
подходы любые

@Катафалк · 12.06.2024, 12:34

Сообщение от COKPOWEHEU

То есть не ознакомились... Это принципиально другой подход к программированию, не тот, к которому вы привыкли

Функциональный, логический, процедурный, ООП, да какой угодно. Метапарадигма остаётся всё той же самой - это описание инструкций в строго формализованной форме в текстовом виде. Как эти инструкции описываются, декларативно ли, или императивно, или ещё как, совершенно не важно. Акцент здесь делается на компьютер, предполагается, что это тупая железяка, которой человек должен указать инструкции что делать, а он может их только исполнять.
Современные же инструменты разработки должны предлагать интеллектуальный подход - с акцентом на разработчика, не на компьютер. Описание программной системы делается на приближенном к естественному языке, в текстовом виде, в виде диаграмм, шаблонов интерфейсов, и т.д. А уже сама система выявляет на основе заданного ТЗ узкие места и в диалоговом режиме, опять же на максимально приближенном к естественному языке, уточняет его и доводит до готового программного продукта.
Именно такой должна быть система разработки ПО XXI века, а не очередной ЯП, в котором заменили скобочки на другие скобочки и стопицоп фреймворков, каждый из которых отличается только тем, насколько больше ресурсов, и человеческих на разработку и компьютерных на выполнение, сожрёт больше, чем предыдущий.

@Ludwig Valentin · 12.06.2024, 13:21

Сообщение от Катафалк

Функциональный, логический, процедурный, ООП, да какой угодно.

я заявляю, что функциональный и процедурный - практически то же самое.

Сообщение от Катафалк

Как эти инструкции описываются, декларативно ли, или императивно, или ещё как, совершенно не важно.

а это уже важно.

Сообщение от Катафалк

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

существует же UML и языки описания моделей

Сообщение от Катафалк

Именно такой должна быть система разработки ПО XXI века, а не очередной ЯП, в котором заменили скобочки на другие скобочки и стопицоп фреймворков, каждый из которых отличается только тем, насколько больше ресурсов, и человеческих на разработку и компьютерных на выполнение, сожрёт больше, чем предыдущий.

а по-моему, когда человек кодит сам, он лучше знает, чего хочет получить.

@Катафалк · 12.06.2024, 13:37

Сообщение от Ludwig Valentin

а это уже важно.

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

Сообщение от Ludwig Valentin

существует же UML и языки описания моделей

И что толку? Есть ли системы, которые могут на основе UML создать готовый программный продукт, а при неполноте ТЗ - потребовать его уточнения в диалоговом режиме?
По факту, UML - это тоже строго формализованное описание, но не в текстовом виде, а в виде диаграммы.

Сообщение от Ludwig Valentin

а по-моему, когда человек кодит сам, он лучше знает, чего хочет получить.

Разумеется, и интеллектуальная диалоговая система разработки ПО поможет этому человеку ускорить разработку того, что он хочет получить, в разы, если не в десятки.

@Ludwig Valentin · 12.06.2024, 13:46

Сообщение от Катафалк

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

ну декларация явно не набор инструкций

Сообщение от Катафалк

И что толку? Есть ли системы, которые могут на основе UML создать готовый программный продукт, а при неполноте ТЗ - потребовать его уточнения в диалоговом режиме?
По факту, UML - это тоже строго формализованное описание, но не в текстовом виде, а в виде диаграммы.

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

Сообщение от Катафалк

Разумеется, и интеллектуальная диалоговая система разработки ПО поможет этому человеку ускорить разработку того, что он хочет получить, в разы, если не в десятки.

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

@testuser2 · 12.06.2024, 14:51

Сообщение от Катафалк

И что толку? Есть ли системы, которые могут на основе UML создать готовый программный продукт, а при неполноте ТЗ - потребовать его уточнения в диалоговом режиме?

У мя такая догадка, что профессиональные проггеры (как и любые специалисты в любой другой области) же не будь дураки, стараются как-то огородить свой бизнес от чрезмерного притока предложения. Потому, что если сделать супер удобный и интуитивно понтный продукт возникнет избыточное колличество специалистов или "специалистов".. И если даже создают что-то подобное, то возможно даже закладывают какие-то изъяны, чтобы это работало где-то медленней, глючнее и т.д., Это конечно может быть частичной правдой, но глядя на некоторые решения иногда возникает такая мысль

@Катафалк · 12.06.2024, 15:33

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

Добавлено через 3 минуты

Сообщение от Ludwig Valentin

ну декларация явно не набор инструкций

Ну не хотите называть набором инструкций, называйте описанием. Суть то в другом - это в любом случае строго формализованное описание. Как и UML.

Сообщение от Ludwig Valentin

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

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

@voraa · 12.06.2024, 22:31

Сообщение от Катафалк

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

Даже если один человек будет объяснять другому "на максимально приближенном к естественному, неформализованном языке", то не факт, что они всегда поймут друг друга. Машина точно не всегда поймет. Или не поймет с первого раза. Придется объяснять второй, третий.... десятый раз. Потом плюнешь и напишешь все на формализованном языке.

@Ludwig Valentin · 13.06.2024, 03:59

Сообщение от testuser2

У мя такая догадка, что профессиональные проггеры (как и любые специалисты в любой другой области) же не будь дураки, стараются как-то огородить свой бизнес от чрезмерного притока предложения. Потому, что если сделать супер удобный и интуитивно понтный продукт возникнет избыточное колличество специалистов или "специалистов".. И если даже создают что-то подобное, то возможно даже закладывают какие-то изъяны, чтобы это работало где-то медленней, глючнее и т.д., Это конечно может быть частичной правдой, но глядя на некоторые решения иногда возникает такая мысль

Это просто вредительство.

Добавлено через 1 минуту

Сообщение от Катафалк

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

Так он о ней и думает. Но формализует логику для машины.

@Alex TROCKII · 13.06.2024, 10:28 **[ТС]**

ужос просто. смотрю на цпп и на си, аж глаз дёргается после питона и шарпа

Алексей1153 · 13.06.2024, 10:32

Alex TROCKII, да все уж поняли, зачем повторяться

@Alex TROCKII · 13.06.2024, 10:42 **[ТС]**

а что ты кодишь на этом си? просто интересно

Алексей1153 · 13.06.2024, 10:46

Alex TROCKII, я не на си, я на C++. Мне нравится. Шарп пару раз пробовал когда-то - мне не заходит. Питон в самом начале процесса изучения. Ну, забавный. Слишком вольное обращение с типами и полями вызывает подозрение

@COKPOWEHEU · 13.06.2024, 11:49

Сообщение от Ludwig Valentin

Знаю, что Лисп оперирует списками.

Дело не в списках, а в том, что в лиспе может, например, вообще не быть циклов. Сам подход к написанию кода отличается. Но я не лиспер, подробностей или примеров привести не смогу.
А на счет "все - список" меня в свое время порадовал подход Lua, где все - таблица (ну кроме пары совсем уж базовых типов). При том, что язык процедурный / ооп. И массив - таблица, и объект - таблица (даже приватные поля организовать можно).

Сообщение от Катафалк

Функциональный, логический, процедурный, ООП, да какой угодно. Метапарадигма остаётся всё той же самой - это описание инструкций в строго формализованной форме в текстовом виде.

Вы про машину Тьюринга слышали? Я вот затруднился бы на ней выделить отдельные функции. Или какой-нибудь VHDL (язык для ПЛИС). Да даже makefile совершенно не похож на Си.

Сообщение от Катафалк

Современные же инструменты разработки должны предлагать интеллектуальный подход

Современные инструменты разработки чего? Ядро ОС - одно дело, числодробилка - другое, игра третье, веб-сайт четвертое. Нечеткая логика вроде распознавания объектов - вообще отдельная область.
От того же ядерного программирования требуется надежность, скорость и предсказуемость, чего вы никак не обеспечите, скажем, нейросеткой.

Сообщение от testuser2

У мя такая догадка, что профессиональные проггеры (как и любые специалисты в любой другой области) же не будь дураки, стараются как-то огородить свой бизнес от чрезмерного притока предложения.

Не надо приписывать злому умыслу то, что можно объяснить обычным раздолбайством. Индус-триальный программист ведь не для себя пишет, а для заказчика или работодателя. Насколько мутное ТЗ ему дали, сколько времени отвели и сколько заплатили - такой результат и получили. Не всегда программист даже заинтересован в "успехе" своей программы.
А если говорить о том, "как должно быть", так наш форум отличный пример. Люди тут сидят не на зарплате, но все равно пытаются помочь друг другу и даже халявщикам (хотя частенько, увы, и вредят им, выдавая готовые решения).

Сообщение от voraa

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

Хуже того, машина не поймет, что не поняла. И будет делать как поняла. А "программист", не знающий как это устроено, ничего сделать не сможет.

@Катафалк · 13.06.2024, 16:11

Сообщение от COKPOWEHEU

Вы про машину Тьюринга слышали? Я вот затруднился бы на ней выделить отдельные функции. Или какой-нибудь VHDL (язык для ПЛИС). Да даже makefile совершенно не похож на Си.

Не очень понял, причем тут VHDL и Си, и машина Тьюринга.

Сообщение от COKPOWEHEU

Современные инструменты разработки чего? Ядро ОС - одно дело, числодробилка - другое, игра третье, веб-сайт четвертое. Нечеткая логика вроде распознавания объектов - вообще отдельная область.
От того же ядерного программирования требуется надежность, скорость и предсказуемость, чего вы никак не обеспечите, скажем, нейросеткой.

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

Добавлено через 2 минуты

Сообщение от COKPOWEHEU

Хуже того, машина не поймет, что не поняла. И будет делать как поняла.

Если не научите понимать, то не поймет. Естественно, нужно делать машину, которая выявляет все возможные белые пятна строя максимально полное ТЗ перед выполнением. ChatGPT, который соглашается с любым бредом, который вы ему скажете, тут не пойдёт.

Сообщение от COKPOWEHEU

А "программист", не знающий как это устроено, ничего сделать не сможет.

Он сможет уточнить ТЗ для системы и она внесет необходимые правки. Естественно, руками лезть опять в формализованный код человеку не нужно ни при каких обстоятельствах, иначе какой во всем смысл?

@testuser2 · 13.06.2024, 16:31

Содного из программистских ТГ-чатов

Вы своими слоями абстракции пытаетесь оправдать потуги бизнеса сократить свои расходы. Он сокращает их за ваш счет. Это вы делаете слои абстракции, а потом идете нахер на улицу, а бизнес раздает это направо и налево. Вы еще не поняли этого? Пора бы начинать понимать. До какой степени вы собрались абстракции повышать? До уровня, когда любой бомж, общаясь с чатомГПТ одной кнопкой будет собирать готовый проект? Вам, как работнику, изучающему программирование много лет, это будет выгодно?

И дальше там в обсуждении

Артем, [13.06.2024 20:37]
Так ты боишься просто, что тебя крепкие, молодые ребята заменят, получается. Мне выгодно, чтобы мир развивался, он будет развиваться, если искоренить закостенелость. Иначе ты до сих пор зубами бы дырки в перфокартах бил

Michael, [13.06.2024 20:39]
Так меня уже заменили ребятки. Я об этом рассказываю. А ты не боишься, что тебя заменит бомж с клавиатурой? Стоило бы начать бояться.

@COKPOWEHEU · 13.06.2024, 20:04

Сообщение от Катафалк

Не очень понял, причем тут VHDL и Си, и машина Тьюринга.

Еще примеры разных парадигм программирования, которые не похожи на процедурное / ооп

Сообщение от Катафалк

Впрочем, какие уж тут автоматизации, когда сами никак кодить качественно не можем научиться, качество софта год от года все хуже и хуже.

Вот именно поэтому, что не кодить учимся, а "интеллектуальные" конфигурялки изучаем.

Сообщение от Катафалк

Он сможет уточнить ТЗ для системы

Для того, чтобы знать какие именно элементы ТЗ машина поняла неправильно и как именно их уточнить, придется знать внутреннее устройство.

@Ludwig Valentin · 13.06.2024, 21:28

Сообщение от COKPOWEHEU

Для того, чтобы знать какие именно элементы ТЗ машина поняла неправильно и как именно их уточнить, придется знать внутреннее устройство.

браво, маэстро!

@Катафалк · 13.06.2024, 21:39

Сообщение от COKPOWEHEU

Еще примеры разных парадигм программирования, которые не похожи на процедурное / ооп

Есть много разных других парадигм, и что? Метапарадигма одна и та же - строго формализованное описание, как правило - в текстовом виде.

Сообщение от COKPOWEHEU

Для того, чтобы знать какие именно элементы ТЗ машина поняла неправильно и как именно их уточнить, придется знать внутреннее устройство.

Нет, очевидно. Вернее, если это тупая машина то да. Но мы то говорим о развитой интеллектуальной системе. Такая система сама должна определять неоднозначные элементы ТЗ и разрешать неоднозначности в диалоговом режиме. А не человек за нее будет искать что она там не поняла. Человек лишь валидирует финальный результат и при необходимости запрашивает доработки.

Сообщение от COKPOWEHEU

Вот именно поэтому, что не кодить учимся, а "интеллектуальные" конфигурялки изучаем.

Чтобы их изучать, их хорошо было бы сначала создать.

Новые блоги и статьи Все статьи Все блоги /
Жизня: рисунок укладки багажа, сделанный клодом anaschu 21.08.2026 Сделал 15 снимков, он по снимкам сделал схему.	Был там один разговор по поводу свободы в материальном мире. kumehtar 19.08.2026 Суть: рассматривается живое существо, оказавшееся внутри довольно странной системы (этого мира) и пытающееся обустроить в ней свой кусок пространства. Жизнь действительно предъявляет каждому. . .	Когда логика программы не спасает от человеческих ошибок Maks 18.08.2026 В последнее время всё чаще и чаще сталкиваюсь с таким явлением, как абсолютная невнимательность (или глупость) пользователей. Проявляется это чаще всего на работе в коллективе. Допустим, человек с. . .	Лето уходит kumehtar 17.08.2026
Мысли в слух kumehtar 17.08.2026 Забавно, насколько сейчас стала доступна информация. Например о магии, духовном развитии, медитациях, и других подобных направлениях, ранее зачастую тайных, передаваемых от учителя к ученику. Хотя. . .	Перемещение строк из ТЧ в другой документ с учетом текущего пробега Maks 17.08.2026 Реализация из решения ниже выполнена на примере нетипового документа "Автозапчасти", с ТЧ "Шины". За основу взят алгоритм отсюда: https:/ / www. cyberforum. ru/ blogs/ 359708/ 10838. html Задача: . . .	Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .	Часы электронные Uhbif79 12.08.2026 Выкладываю программу часов. Программа позволяет: 1. Использовать системное время и дату, 2. Есть возможность вводить время и дату вручную. 3. Реализованы 2 будильника: начало и конец рабочего дня. . . .

@Alex TROCKII 3 / 4 / 1 Регистрация: 18.08.2017 Сообщений: 77

	Холивары вокруг C++ 26.05.2024, 13:30. Показов 13333. Ответов 160 Метки нет (Все метки) админы совсем не хотят менять мне ник, потому что у меня нету 100 сообщений. мусор создавать в виде пустых сообщений не вижу смысла. так давайте немного философии. На этом форуме живет один мой очень древний знакомый Андрээ С, который здесь точно и однозначно был админом. когда то давно он даже активно пытался меня банить, когда я любил немного пошалить и потролить кодеров. Так вот, прошло лет 10, а наша основная тема спора оказывается до сих пор актуальна. Спор у меня недавно возник с другим кодером, потому с Андрэ Мандрэ мы очень давно не общались. Суть спора можно объяснить одной его фразой: "С# это кастрированный с++". ну типа существует язык цпп для реальных программистов, а си шарп это какая та дичь не понятно для кого вообще и не понятно зачем. Дело в том, что я даже поверил этому и начал один из своих проектов кодить на цпп. Ну думал такой, что щас подтяну знания реально крутого языка, на котором написаны почти все крупные проекты. ФИГ! Я не помню точно на чем я забуксовал, но точно помню финальную мысль - это кал вонючий, на котором нету вообще никаких удобств, траблы с библиотеками (может быть сейчас не актуально уже) и вообще как работать с объектами когда всё настолько хреново. вот простые моменты, от которых жопа сразу сгорает мгновенно: 1. статические массивы. если мне надо добавить что-то в середине массива, то это танцы с бубном с пересозданием. 2. надо следить за памятью и чистить все неиспользуемые переменные, ибо память бесконтрольно засирается 3. отсутствие таких коллекций как List<T>, ObservableCollection, dictionary и тд... просто без комментариев 4. отсутсвие linq n. примитивная низкоуровневость дальше можно просто не перечислять. вот этих пунктов достаточно, чтобы вместо нормальной разработки какой нибудь полезной штуковины мне пришлось бы заниматься реальным дрочевом с низкоуровневым кодом, где искать где какие индексы не так были назначены... в си шарпе у меня объекты на объектах, они крупные и каждый класс насыщен большим количеством логики. я просто не представляю сколько времени мне бы пришлось убить на возню в с++, это просто страшно. я понимаю конечно, что как бы "СКОРОСТЬ РАБОТЫ РЕШАЕТ!", что софт на шарпе по определению работает медленнее потому что управляемый код и тд... но всему своё место. я не майнер пишу, который должен быть оптимизирован по максимуму. есть смысл всю логику перегонять на быстрые языки, если это игровой движок - ну там чем быстрее код работает, тем больше объектов отрисовывает, тут как бы ок. есть смысл нанять толпу батанов из вычислительного центра НАСА, чтобы кодили 24/7 каждую мелочь на цпп и гнались за каждой выйгранной миллисекундой, вполне возможно это действительно оправдано. только в обычном бытовом коде это вообще нафиг не нужно и мне не понятны такие люди, которые хейтят питон и си шарп. и сколько пересекаюсь с разными кодерами, каждый десятый попадается с такой пулей в голове. питон то перестали хейтить, ибо нейронки и это уже не тот питон что был на 3 версии. а на си шарп гонят конкретно. коточе как то так. вопросов у меня нету, +1 к сообщениям накатал. спасибо за внимание. приятной вам работы с цпп, а лучше просто на си. ну так, чтобы больше хардкора, чтобы доказать всем что ты настоящий программист 0

@Alex TROCKII 3 / 4 / 1 Регистрация: 18.08.2017 Сообщений: 77
	13.06.2024, 10:28 [ТС]
	ужос просто. смотрю на цпп и на си, аж глаз дёргается после питона и шарпа 0

Алексей1153 фрилансер 6500 / 5731 / 1134 Регистрация: 11.10.2019 Сообщений: 15,339
	13.06.2024, 10:32
	Alex TROCKII, да все уж поняли, зачем повторяться 0

@Alex TROCKII 3 / 4 / 1 Регистрация: 18.08.2017 Сообщений: 77
	13.06.2024, 10:42 [ТС]
	а что ты кодишь на этом си? просто интересно 0

Алексей1153 фрилансер 6500 / 5731 / 1134 Регистрация: 11.10.2019 Сообщений: 15,339
	13.06.2024, 10:46
	Alex TROCKII, я не на си, я на C++. Мне нравится. Шарп пару раз пробовал когда-то - мне не заходит. Питон в самом начале процесса изучения. Ну, забавный. Слишком вольное обращение с типами и полями вызывает подозрение 0