Частота использования ругательных слов в отношении языков программирования на реддите за 2018 год
Пфф, был бы здесь Prolog...
30.12.2018, 21:13
Это такой же язык программирования. Если покурить его примерно месяцок то понимаешь что он вырождается в процедурный из за некоторых фич именно пролога
Скорее всего это был один и тот же коммент.
JavaScript+php+mysql = образованный человек xD
Внезапно это так, и там реально что то можно делать.
Как я много раз объяснял, сложность С++ заключается не в С++.
В плане синтаксиса С++ в общем-то ничего особенного по сравнению с любым другим современным языком. Разница находится снаружи. Когда ты пишешь на каком-нибудь managed-говне, всё что тебя заботит - это твоя собственная прога, а все техники оптимизации заключаются в том, чтобы запускать сборщик мусора пореже. Программиста на С++ заботит не только собственная прога, а то, чтобы получить именно на выхлопе наиболее быстро выполняющийся на железе код. Для этого нужно знать особенности работы железа, как ядра обмениваются кэшированными данными чтобы гонять твоё даже однопоточное приложение на разных ядрах, как читается и алигнится память, как минимально ветвить программу чтобы конвейер проца не простаивал, и выхватывал максимальное опережение чтобы данные были готовы к моменту выполнения, где разместить барьеры памяти, чтобы синхронизация кэша с памятью проходила максимально гладко и быстро, и прочие выкрутасы, благодаря которым код на С++ железо жамкает резвее, как бы managed-говны с виртуальными машинами не пыжились. Всё это заставляет специалиста по плюсам знать не только железные дела, но и разбираться в тонкостях ОБВМ того, кто этот код генерирует - компилятора, и писать код не для людей, а для компилятора, подстраивая программу под его внутренний мир с целью заставить его сгенерить то что нужно для наискорейшего выполнения железом.
tl;dr По вхождению плюсы не сложнее любого другого языка, но труден на профессиональном уровне - мастер до-диеза печётся только о своём коде, в то время как мастеру плюсов приходится знать внутренний мир железа и ублажать компилятор, получая в качестве вознаграждения код, который способен работать до 40 раз быстрее полного аналога на до-диезе за счёт срезания железных углов, что и продолжает обеспечивать плюсам место под солнцем в нише продуктов требующих высокой оптимизации.
В плане синтаксиса С++ в общем-то ничего особенного по сравнению с любым другим современным языком. Разница находится снаружи. Когда ты пишешь на каком-нибудь managed-говне, всё что тебя заботит - это твоя собственная прога, а все техники оптимизации заключаются в том, чтобы запускать сборщик мусора пореже. Программиста на С++ заботит не только собственная прога, а то, чтобы получить именно на выхлопе наиболее быстро выполняющийся на железе код. Для этого нужно знать особенности работы железа, как ядра обмениваются кэшированными данными чтобы гонять твоё даже однопоточное приложение на разных ядрах, как читается и алигнится память, как минимально ветвить программу чтобы конвейер проца не простаивал, и выхватывал максимальное опережение чтобы данные были готовы к моменту выполнения, где разместить барьеры памяти, чтобы синхронизация кэша с памятью проходила максимально гладко и быстро, и прочие выкрутасы, благодаря которым код на С++ железо жамкает резвее, как бы managed-говны с виртуальными машинами не пыжились. Всё это заставляет специалиста по плюсам знать не только железные дела, но и разбираться в тонкостях ОБВМ того, кто этот код генерирует - компилятора, и писать код не для людей, а для компилятора, подстраивая программу под его внутренний мир с целью заставить его сгенерить то что нужно для наискорейшего выполнения железом.
tl;dr По вхождению плюсы не сложнее любого другого языка, но труден на профессиональном уровне - мастер до-диеза печётся только о своём коде, в то время как мастеру плюсов приходится знать внутренний мир железа и ублажать компилятор, получая в качестве вознаграждения код, который способен работать до 40 раз быстрее полного аналога на до-диезе за счёт срезания железных углов, что и продолжает обеспечивать плюсам место под солнцем в нише продуктов требующих высокой оптимизации.
Когда я пишу стену текста, она выглядит так: http://joyreactor.cc/post/3723581
А это так, утренняя разминка.
А это так, утренняя разминка.
> А это так, утренняя разминка.
По вхождению плюсы не сложнее любого другого языка, но труден на профессиональном уровне - мастер до-диеза печётся только о своём коде, в то время как мастеру плюсов приходится заходить в каждый топик о программировании на любом ресурсе и ублажать своё ЧСВ.
По вхождению плюсы не сложнее любого другого языка, но труден на профессиональном уровне - мастер до-диеза печётся только о своём коде, в то время как мастеру плюсов приходится заходить в каждый топик о программировании на любом ресурсе и ублажать своё ЧСВ.
Заказов на C++ со знанием внутренностей всё меньше. Народу всё больше требуются игры с рекламой под смартфоны, сайтики и прочие мелочи под языки с GC.
Свободного времени у профессионала по возне с низким уровнем становится всё больше - можно писать длинные портянки в интернетах.
Свободного времени у профессионала по возне с низким уровнем становится всё больше - можно писать длинные портянки в интернетах.
cpp, имхо, на 80% сложен не тем, что он низкоуровневый и там, соответственно, есть прямой доступ к памяти, а ещё тем, что ему сто лет в обед и он состоит из сплошного легаси. В итоге овладеть целиком языком - за гранью добра и зла. Каждый кодер владеет своим суржиком плюсов. Вот сравни плюсы с ныне почти почившим Object Pascal\Delphi. Ну чего там в Delphi учить? А ведь указатели на месте, выделение памяти и её освобождение на месте, деструкторы всякие тоже. ООП тоже на месте.
А вообще, у меня лично, психологическая травма, после того как я стал гуглить, как же передать по ссылке в какой-либо метод двумерный массив произвольной длины (cpp 98). Увиденное не развидеть.
А вообще, у меня лично, психологическая травма, после того как я стал гуглить, как же передать по ссылке в какой-либо метод двумерный массив произвольной длины (cpp 98). Увиденное не развидеть.
Что ты блять несёшь?
С++ легаси... где вы его находите? Сколько лет работаю, а ни одного прям легаси легаси ни разу не встретил. С++ в принципе не майнтенабелен, поэтому легаси проекты на нём просто не живут. А суржиком пишут там, где нет стандартиста, способного вкатить нерадивым суржикописцам двести кубиков последнего стандарта.
Делфи имхо был мертворождённым, но из-за богатой практики некрофилии поцкаля в отечественных вузах, его труп некоторое время ходил и ел порядочным людям моск. После чего собственный раздувающийся рантайм погубил и его тоже.
> как же передать по ссылке в какой-либо метод двумерный массив произвольной длины (cpp 98)
Оборачиваешь в класс, передаёшь ссылку на класс. А если есть криворукие, то вообще закрыть нахуй прямой доступ к данным без особой надобности. Я лично в дизайне интерфейсов придерживаюсь правила, что ввод от живого человека будет совершенно произвольным, и возможность прицелиться в ногу нужно отключить by design.
С++ легаси... где вы его находите? Сколько лет работаю, а ни одного прям легаси легаси ни разу не встретил. С++ в принципе не майнтенабелен, поэтому легаси проекты на нём просто не живут. А суржиком пишут там, где нет стандартиста, способного вкатить нерадивым суржикописцам двести кубиков последнего стандарта.
Делфи имхо был мертворождённым, но из-за богатой практики некрофилии поцкаля в отечественных вузах, его труп некоторое время ходил и ел порядочным людям моск. После чего собственный раздувающийся рантайм погубил и его тоже.
> как же передать по ссылке в какой-либо метод двумерный массив произвольной длины (cpp 98)
Оборачиваешь в класс, передаёшь ссылку на класс. А если есть криворукие, то вообще закрыть нахуй прямой доступ к данным без особой надобности. Я лично в дизайне интерфейсов придерживаюсь правила, что ввод от живого человека будет совершенно произвольным, и возможность прицелиться в ногу нужно отключить by design.
Ась? Я же не про legacy-код на CPP. Я про сам CPP. Он сам legacy. Именно язык. Раздутый и чрезмерно сложный. Причём сложный за зря. Я понимаю когда говорят, что haskell сложный, там есть чему быть сложным. А тут... Честно говоря, из всех языков, с которыми я хоть как-то сталкивался - самый отвратительный это CPP. Разве что после brainfuck-а.
Кстати делфи я привёл как пример языка, который не ебанутый. Довольно простой и понятный. А не как пример офигенного продакшн решения. Как пример что те же самые задачи можно решать на языках, спецификация на которые меньше размера видимой части вселенной.
> Оборачиваешь в класс, передаёшь ссылку на класс
Да, я в итоге всё обернул в struct и таскал этот struct туда-сюда. Для моих говно-нужд хватало.
Кстати делфи я привёл как пример языка, который не ебанутый. Довольно простой и понятный. А не как пример офигенного продакшн решения. Как пример что те же самые задачи можно решать на языках, спецификация на которые меньше размера видимой части вселенной.
> Оборачиваешь в класс, передаёшь ссылку на класс
Да, я в итоге всё обернул в struct и таскал этот struct туда-сюда. Для моих говно-нужд хватало.
> Ась? Я же не про legacy-код на CPP. Я про сам CPP. Он сам legacy. Именно язык. Раздутый и чрезмерно сложный. Причём сложный за зря. Я понимаю когда говорят, что haskell сложный, там есть чему быть сложным. А тут... Честно говоря, из всех языков, с которыми я хоть как-то сталкивался - самый отвратительный это CPP. Разве что после brainfuck-а.
Ситуация примерно десятилетней давности. Сейчас делфятина это вот как раз Ъ-легаси, а С++ регулярно обновляющий стандарт современный язык.
> Кстати делфи я привёл как пример языка, который не ебанутый. Довольно простой и понятный. А не как пример офигенного продакшн решения. Как пример что те же самые задачи можно решать на языках, спецификация на которые меньше размера видимой части вселенной.
Зачем приводить мёртворождённое говно? Язык нужно выбирать под задачу, это так, но если в задаче производительность или железные ограничения стоят первой или второй строчкой, то у тебя нихуя нету выбора.
Ситуация примерно десятилетней давности. Сейчас делфятина это вот как раз Ъ-легаси, а С++ регулярно обновляющий стандарт современный язык.
> Кстати делфи я привёл как пример языка, который не ебанутый. Довольно простой и понятный. А не как пример офигенного продакшн решения. Как пример что те же самые задачи можно решать на языках, спецификация на которые меньше размера видимой части вселенной.
Зачем приводить мёртворождённое говно? Язык нужно выбирать под задачу, это так, но если в задаче производительность или железные ограничения стоят первой или второй строчкой, то у тебя нихуя нету выбора.
> cpp
> возможность прицелиться в ногу нужно отключить by design
ничего на напутал? :)
правильно чувак говорит, легаси. берем книжку времен расцвета плюсов и смотрим хотя бы на хелло ворлд, и берем новую книжку. в старой будет или сишный принтф, который небезопасен, или иостримы, которые тормозные пиздец и 40к строчек темплейтной магии тянут :) для хелло ворлда это конеш не критично, но зачем сразу привыкать к устаревшим методикам? и поэтому в новой книжке будет что-то другое. если вспомнили про юникод, то и вообще сторонняя либа.
в языке большинство исходных техник давно устарели, но не были выкинуты, и прогер вынужден помнить, где там грабли зарыты.
> возможность прицелиться в ногу нужно отключить by design
ничего на напутал? :)
правильно чувак говорит, легаси. берем книжку времен расцвета плюсов и смотрим хотя бы на хелло ворлд, и берем новую книжку. в старой будет или сишный принтф, который небезопасен, или иостримы, которые тормозные пиздец и 40к строчек темплейтной магии тянут :) для хелло ворлда это конеш не критично, но зачем сразу привыкать к устаревшим методикам? и поэтому в новой книжке будет что-то другое. если вспомнили про юникод, то и вообще сторонняя либа.
в языке большинство исходных техник давно устарели, но не были выкинуты, и прогер вынужден помнить, где там грабли зарыты.
> С++ в принципе не майнтенабелен, поэтому легаси проекты на нём просто не живут.
Но C и C++ тянут обратную совместимость настолько, насколько это возможно.
Разработка на C/C++ слишком дорога, компиляторы языков с GC производят такой же быстрый код, последний аргумент - совместимость со старым кодом - убрали.
Выходит, C и C++ не нужны?
Но C и C++ тянут обратную совместимость настолько, насколько это возможно.
Разработка на C/C++ слишком дорога, компиляторы языков с GC производят такой же быстрый код, последний аргумент - совместимость со старым кодом - убрали.
Выходит, C и C++ не нужны?
> Но C и C++ тянут обратную совместимость настолько, насколько это возможно.
Прежний подход ушёл в прошлое, теперь либо ты компилишь старым компилятором (dynamic linking никто не отменял), либо обновляешься и убираешь старьё из кода.
> Разработка на C/C++ слишком дорога
Тем не менее всё ААА выбирает С++ (не очень люблю когда очень разные языки С и С++ упоминают вместе, а Линус за это так вообще нахуй посылает).
> компиляторы языков с GC производят такой же быстрый код
Ну-ну, мечтатели. То-то в ААА видимо совы-эффективные-менеджеры выбирают С++, если есть такие же быстрые альтернативы... нет, пока что манагед-говны даже не близко, и скорее всего никогда не будут близко к написанному грамотным человеком С++ коду.
> последний аргумент - совместимость со старым кодом
не помню чтобы это когда-то было аргументом в принципе.
> Выходит, C и C++ не нужны?
Дуракам они определённо не нужны, дураки в них стреляют себе в ногу.
Прежний подход ушёл в прошлое, теперь либо ты компилишь старым компилятором (dynamic linking никто не отменял), либо обновляешься и убираешь старьё из кода.
> Разработка на C/C++ слишком дорога
Тем не менее всё ААА выбирает С++ (не очень люблю когда очень разные языки С и С++ упоминают вместе, а Линус за это так вообще нахуй посылает).
> компиляторы языков с GC производят такой же быстрый код
Ну-ну, мечтатели. То-то в ААА видимо совы-эффективные-менеджеры выбирают С++, если есть такие же быстрые альтернативы... нет, пока что манагед-говны даже не близко, и скорее всего никогда не будут близко к написанному грамотным человеком С++ коду.
> последний аргумент - совместимость со старым кодом
не помню чтобы это когда-то было аргументом в принципе.
> Выходит, C и C++ не нужны?
Дуракам они определённо не нужны, дураки в них стреляют себе в ногу.
"Разница находится снаружи. Когда ты пишешь на каком-нибудь managed-говне, всё что тебя заботит - это твоя собственная прога, а все техники оптимизации заключаются в том, чтобы запускать сборщик мусора пореже. Программиста на С++ заботит не только собственная прога, а то, чтобы получить именно на выхлопе наиболее быстро выполняющийся на железе код".
Далеко не всем это нужно.
Мне кажется для многих доменов лучше освободить разработчика от железных вопросов. Например, та же связка C#+Unity3d в геймдеве кажется фантастически удобной.
Далеко не всем это нужно.
Мне кажется для многих доменов лучше освободить разработчика от железных вопросов. Например, та же связка C#+Unity3d в геймдеве кажется фантастически удобной.
"Это та самая связка, которая радует нас таким беспросветным потоком говноигр?"
В силу простоты освоения многие любители пробуют себя именно на Unity. Но на Unity пишутся также и ААА-проекты, и интересные инди-проекты.
В силу простоты освоения многие любители пробуют себя именно на Unity. Но на Unity пишутся также и ААА-проекты, и интересные инди-проекты.
Мне оставили удобный и мощный инструмент для создания того, что мне интересно, со спросом на рынке труда и без головной боли из-за памяти.
Что не отменяет того, что и C++ есть свои задачи.
Что не отменяет того, что и C++ есть свои задачи.
На самом деле не так уж и сильно надо печься о железе - достаточно усвоить несколько базовых принципов (SIMD, шаринг кеша между потоками и т д) - они при этом достаточно универсальные, чтобы работать на любом железе (в том числе и на графических картах - хотя своя специфика там конечно есть). Есть некоторые извороты с использованием напрямую векторных функций, выравниванием данных, но есть библиотеки которые помогают с этим справиться (например Vc). Без них выравнивание памяти в С++ выглядит крайне всрато (если нельзя использовать С++17 В плюсах просто это все осложняется за счет ООП - модный хипстер-пидор насидевшись на своих C# напихает кучу говна на абстракциях, не задумываясь о том - что такое виртуальная таблица - и охуеет от просаживания производительности. Хотя может и не охуеет - моя первая программа на С++ была кривой как мое ебло, но работала в два раза быстрей чем на жабе с которой я работал уже несколько лет.
Щас работаю в области высокопроизводительных вычислений и пишу на ебучем фортране (потому что все пишут на нем). Те моменты, когда удается поработать с плюсами, воспринимаются как благословение божье
Щас работаю в области высокопроизводительных вычислений и пишу на ебучем фортране (потому что все пишут на нем). Те моменты, когда удается поработать с плюсами, воспринимаются как благословение божье
Ну и зачем мне с этим мудохаться если заказчику нужен результат? Это как вместо того, что бы собирать машину из готовых частей каждый раз изобретать колесо, двигатель, рулевую систему и т.п. Да может быть твое колесо будет лучше ехать именно в этой местности(а может и нет), но время и усилия потраченное на разработку несоизмеримы с результатом.
А если требуемый результат это определенный уровень производительности? Говоря твоим языком - кто-то будет рад форд фокусу тольяттинского разлива, а кому-то Bugatti Veyron нужен. И новый спорткар спроектировать - это не форд фокус Zk19+ собрать - стандартными деталями сыт не будешь
Интересно тогда почему существует область под названием "высокопроизводительные вычисления"? Да и опять же движки игровые пишутся на С++ (ладно возможно за исключением Unity - но мы знаем что он не шибко-то производителен). Конечно не каждый их пишет, но это не значит, что высокая производительность нужна только на контроллерах. Постановка производительности на второй план и привела к тому, что весь современный софт жрет бесконечное количество памяти при не сильно большом наполнении функциональностью.
(оффтоп) как правило разработка Ford Focus (и любой другой бюджетной модели) идёт дольше, а стоит дороже, т.к. автомобиль должен быть одновременно и многоцелевым, и доступным
Я сам не очень понимаю людей, которые пишут на С++ там где не надо писать на С++. Если тебе надо формочки и бизнес-логику, ну и намудохай на шарпе, с бекендом на яве, и хули тебе от С++ понадобилось?
С другой стороны, вон фейсбук перешёл с похапе на машинно-генерируемый перевод похапе на С. Производительность выросла на 33%.
С другой стороны, вон фейсбук перешёл с похапе на машинно-генерируемый перевод похапе на С. Производительность выросла на 33%.
>В плане синтаксиса С++ в общем-то ничего особенного по сравнению с любым другим современным языком.
Язык вырвиглазный по сравнению с C# и не пытается от этого уйти. Достаточно посмотреть, как выглядят указатели на функции в C# и C++ или сравнить дженерики.
>Всё это заставляет специалиста по плюсам знать не только железные дела, но и разбираться в тонкостях ОБВМ того, кто этот код >генерирует - компилятора, и писать код не для людей, а для компилятора, подстраивая программу под его внутренний мир с >целью заставить его сгенерить то что нужно для наискорейшего выполнения железом.
Преждевременная оптимизация корень всех бед. В итоге получается вырвиглазных несопровождаемый код. В книге "Совершенный код" говорится, что сначало нужно получить рабочую программу, а потом если она не соответствует требованиям производительности, то производить микро-оптимизации. Возможно, нужно лишь 1 цикл поправить и все будет в шоколаде. Для этого существует много современных профилировщиков.
>managed-говны
Не понимаю твоей желчи в сторону управляемых языков программирования. Да, может быть они и жрут памяти немного больше, чем при ручном управлении, но память сейчас дешевая. Алгоритмы сборки мусора сейчас совершеннее, чем были ранее => не вызывают заметных для пользователя тормозов.
Зачем знать тонкости работы двигателя, если я могу взять машину и поехать на ней?
Язык вырвиглазный по сравнению с C# и не пытается от этого уйти. Достаточно посмотреть, как выглядят указатели на функции в C# и C++ или сравнить дженерики.
>Всё это заставляет специалиста по плюсам знать не только железные дела, но и разбираться в тонкостях ОБВМ того, кто этот код >генерирует - компилятора, и писать код не для людей, а для компилятора, подстраивая программу под его внутренний мир с >целью заставить его сгенерить то что нужно для наискорейшего выполнения железом.
Преждевременная оптимизация корень всех бед. В итоге получается вырвиглазных несопровождаемый код. В книге "Совершенный код" говорится, что сначало нужно получить рабочую программу, а потом если она не соответствует требованиям производительности, то производить микро-оптимизации. Возможно, нужно лишь 1 цикл поправить и все будет в шоколаде. Для этого существует много современных профилировщиков.
>managed-говны
Не понимаю твоей желчи в сторону управляемых языков программирования. Да, может быть они и жрут памяти немного больше, чем при ручном управлении, но память сейчас дешевая. Алгоритмы сборки мусора сейчас совершеннее, чем были ранее => не вызывают заметных для пользователя тормозов.
Зачем знать тонкости работы двигателя, если я могу взять машину и поехать на ней?
> не вызывают заметных для пользователя тормозов
Ну не скажи. Они работают быстро, пока памяти много. Чем ближе ты к пределу, тем жоще тормоза. Причём формально программа ещё работает, а по факту 95+% времени пытается освободить ну хоть что-нибудь. Лучше бы просто сдохла и перезапустилась, всё равно большая часть её памяти это утечки. Причём это касается любых языков с GC. Хоть JS, хоть C#.
Ну не скажи. Они работают быстро, пока памяти много. Чем ближе ты к пределу, тем жоще тормоза. Причём формально программа ещё работает, а по факту 95+% времени пытается освободить ну хоть что-нибудь. Лучше бы просто сдохла и перезапустилась, всё равно большая часть её памяти это утечки. Причём это касается любых языков с GC. Хоть JS, хоть C#.
> Они работают быстро, пока памяти много. Чем ближе ты к пределу, тем жоще тормоза. Причём формально программа ещё работает, а по факту 95+% времени пытается освободить ну хоть что-нибудь
Расскажи это энтерпрайз Java системам которые работают с 20-40 гигами оперативы. За последние годы разработки GC шагнули далеко вперед и значительная часть работы происходит параллельно с работой программы
Расскажи это энтерпрайз Java системам которые работают с 20-40 гигами оперативы. За последние годы разработки GC шагнули далеко вперед и значительная часть работы происходит параллельно с работой программы
Я не понял, что ты хотел сказать, если честно. GC развиваются - правда, к примеру я слежу за GC в v8. GC работает одновременно с работой программы - правда, а как ещё?
Но сказать то ты что хотел? Что мне такого нужно рассказать кровавому ынтерпрайзу, чего они сами не знают?
И пассаж про 20-40 GiB ОЗУ я не понял. Прямо совсем. Поменяй 20 на 2 или на 200. Что изменилось? Ты о чём?)
Но сказать то ты что хотел? Что мне такого нужно рассказать кровавому ынтерпрайзу, чего они сами не знают?
И пассаж про 20-40 GiB ОЗУ я не понял. Прямо совсем. Поменяй 20 на 2 или на 200. Что изменилось? Ты о чём?)
> Язык вырвиглазный по сравнению с C# и не пытается от этого уйти. Достаточно посмотреть, как выглядят указатели на функции в C# и C++ или сравнить дженерики.
Твои знания по плюсам устарели, теперь везде автовыведение типа не хуже шарпа, а std::function и лямбды давно заменили С-подобные указатели на функции.
> Преждевременная оптимизация корень всех бед. В итоге получается вырвиглазных несопровождаемый код. В книге "Совершенный код" говорится, что сначало нужно получить рабочую программу, а потом если она не соответствует требованиям производительности, то производить микро-оптимизации. Возможно, нужно лишь 1 цикл поправить и все будет в шоколаде. Для этого существует много современных профилировщиков.
В С++, по крайней мере в высокооптимизированной нише, подход к разработке иной, чем для бизнес-приложений где безбажность важнее производительности. Там сперва строится прототип, и по его скелету проектируется готовый продукт вместе с оптимизацией сразу. И сразу же настраивается на дейли билде сравнение затрачиваемого времени на рендер кадра с профилировщиком, с автоматическим репортом, и сравнивается с другими продуктами на этом же движке, чтобы работало "не хуже чем Х", разбор полётов "почему тормоза" и оптимизация будут идти на любом этапе - производительность обычно важнее багов, кроме самых критических.
> Не понимаю твоей желчи в сторону управляемых языков программирования.
Однажды меня наняли загнать С#-проект в телефоны. В не самые новые телефоны. Количество говна которое я отгрёб от managed-памяти всё время желающей откусить больше чем есть, и запуском сборщика мусора в самые неподходящие моменты на моно 2.0 - ты себе просто не представляешь. Лучше ручками сделаю, чем ещё раз полагаться на моно...
Твои знания по плюсам устарели, теперь везде автовыведение типа не хуже шарпа, а std::function и лямбды давно заменили С-подобные указатели на функции.
> Преждевременная оптимизация корень всех бед. В итоге получается вырвиглазных несопровождаемый код. В книге "Совершенный код" говорится, что сначало нужно получить рабочую программу, а потом если она не соответствует требованиям производительности, то производить микро-оптимизации. Возможно, нужно лишь 1 цикл поправить и все будет в шоколаде. Для этого существует много современных профилировщиков.
В С++, по крайней мере в высокооптимизированной нише, подход к разработке иной, чем для бизнес-приложений где безбажность важнее производительности. Там сперва строится прототип, и по его скелету проектируется готовый продукт вместе с оптимизацией сразу. И сразу же настраивается на дейли билде сравнение затрачиваемого времени на рендер кадра с профилировщиком, с автоматическим репортом, и сравнивается с другими продуктами на этом же движке, чтобы работало "не хуже чем Х", разбор полётов "почему тормоза" и оптимизация будут идти на любом этапе - производительность обычно важнее багов, кроме самых критических.
> Не понимаю твоей желчи в сторону управляемых языков программирования.
Однажды меня наняли загнать С#-проект в телефоны. В не самые новые телефоны. Количество говна которое я отгрёб от managed-памяти всё время желающей откусить больше чем есть, и запуском сборщика мусора в самые неподходящие моменты на моно 2.0 - ты себе просто не представляешь. Лучше ручками сделаю, чем ещё раз полагаться на моно...
В целом отчасти он прав - метапрограммирование градус вырвиглазности наращивает на раз. В итоге приходится напихивать typedef и auto, что на мой взгляд сильно портит читаемость кода. Хотя конечно это может быть только мое восприятие, но мне все же приятней вместо auto видеть конкретный тип, особенно если переменной присваивается результат выполнения какого-либо метода
В книге "совершенный код" много чего говорится, но к реальности это мало относится. Ну и в реальности не бывает преждевременной оптимизации, просто код надо писать изначально задумываясь о производительности, хотя бы чуть чуть, в противном случае нахуярив говна заоптимизить будет тяжелее чем все переписать.
>который способен работать до 40 раз
по данным Benchmarks Game от команды Debian - в среднем преимущество примерно двухкратное, что в общем-то тоже не мало
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/csharpcore-gpp.html
по данным Benchmarks Game от команды Debian - в среднем преимущество примерно двухкратное, что в общем-то тоже не мало
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/csharpcore-gpp.html
что есть "нормальные тесты для Managed языков" ?
40 раз откуда взял? только что из пальца высосал?
2-3 раза от силы, если бездумно хуячить, не задумываясь о производительности на обоих языках. если задумываться - там уже не разы будут, а проценты.
40 раз это разве что gpu заюзать, но это уже не к языкам относится, ничто не мешает заюзать gpu хоть их шарпа, хоть из питона.
не надо забывать, что плюсы компиляются ровно так, как написаны, а шарп джитится после накопления статистики. со временем код может перекомпиляться несколько раз и стать даже быстрее плюсового за счёт более агрессивного инлайна и выпиливания ненужных кусков.
в этом плане что-то кардинально лучшее - это только собрать 1 раз софтину, погонять ее, собрать статистику, потом сунуть в компилятор для оптимизаций. но в плюсах такого никогда не будет. возможно, будет в d, или в русте.
а также не нужно забывать, что современное железо гораздо сложнее, чем многие о нем думают, от балды из общих соображений что-то там прикидывать, какой код будет быстрее - прокатывает всё реже и реже. надо мерить. что в плюсах, что в шарпе - везде надо.
2-3 раза от силы, если бездумно хуячить, не задумываясь о производительности на обоих языках. если задумываться - там уже не разы будут, а проценты.
40 раз это разве что gpu заюзать, но это уже не к языкам относится, ничто не мешает заюзать gpu хоть их шарпа, хоть из питона.
не надо забывать, что плюсы компиляются ровно так, как написаны, а шарп джитится после накопления статистики. со временем код может перекомпиляться несколько раз и стать даже быстрее плюсового за счёт более агрессивного инлайна и выпиливания ненужных кусков.
в этом плане что-то кардинально лучшее - это только собрать 1 раз софтину, погонять ее, собрать статистику, потом сунуть в компилятор для оптимизаций. но в плюсах такого никогда не будет. возможно, будет в d, или в русте.
а также не нужно забывать, что современное железо гораздо сложнее, чем многие о нем думают, от балды из общих соображений что-то там прикидывать, какой код будет быстрее - прокатывает всё реже и реже. надо мерить. что в плюсах, что в шарпе - везде надо.
плюсовики такие забавные
лучшие инженеры планеты, разрабы компиляторов, им говорят, не сможешь ты, дубина, угадать, как поведет себя компилятор и процессор, я сам не смогу, меряй, не выёбывайся - нет блять, всё равно пойдут лабать говно наобум, но при этом в полной уверенности в своей илитарности
лучшие инженеры планеты, разрабы компиляторов, им говорят, не сможешь ты, дубина, угадать, как поведет себя компилятор и процессор, я сам не смогу, меряй, не выёбывайся - нет блять, всё равно пойдут лабать говно наобум, но при этом в полной уверенности в своей илитарности
Нет, батенька, C++ сложен сам по себе. Описанные проблемы - в основном, сложность низкого уровня, которая к ним только добавляется.
Не зря Мейерс специально пишет книги тупо о том, как писать на C++, чтобы программа просто работала и не падала.
Надо помнить о том, что конструкторы правильно работают только если написаны все вместе, иначе простое безобидное присваивание может привести к двойному удалению в деструкторе.
Придётся узнать, что обычные операторы можно реализовать внутри класса, а сдвиги в поток - вне класса потому, что поток - левый операнд. И чтобы это реализовать, придётся одним из нескольких способов приоткрыть private-члены для оператора.
Придётся научиться выделять память так, чтобы при выбрасывании исключения не было утечки памяти.
Ещё в C++ куча способов инициализировать член. Тут и инициализация через равно, через круглые скобки, через фигурные скобки, через каст и оператор присваивания, значения по умолчанию для типа, аргументы по умолчанию, аргументы по умолчанию у класса-родителя. Вместе эти способы рождают множество комбинаций, которые нужно либо учесть в своём коде, либо правильно прочитать в чужом.
Ещё какая-то жопа с компиляцией шаблонов. Проще всё в *.h сплавить.
Кстати, если у шаблонного класса есть шаблонный метод, и это пишется в реализации (как для *.cpp-файла), то это уже без гуглёжки не напишешь, а чужой код - не проверишь.
А если в теле шаблона берётся тип или шаблон через :: из параметра шаблона, то придётся дописать "typename" или "template" перед этой конструкцией, только это не для произвольного выражения работает, придётся разбавлять код тайпдефами.
Описания типы, прости Господи, слизали со сраной сишки. И если типы STL хоть как-то адекватно описываются, то обычный массив константных указателей на функцию уже требует недюжинной нагрузки на мозг или кучи тайпдефов. И это - тривиальщина. Функция, возвращающая указатель на функцию? Придётся гуглить и учить способ чтения сигнатур по спирали. В Haskell те же типы записываются тривиально.
Ко всему этому добавляется куча случаев неопределённого поведения.
C++ - это зековская феня. Чуть что не так - под шконку, ошибся - пидорнули. После пяти лет программирования к этому привыкаешь и получаешь удовольствие, хотя нормальные люди косо смотрят.
И исправить это можно. Даже ECMAScript пошёл по пути исправления.
Не зря Мейерс специально пишет книги тупо о том, как писать на C++, чтобы программа просто работала и не падала.
Надо помнить о том, что конструкторы правильно работают только если написаны все вместе, иначе простое безобидное присваивание может привести к двойному удалению в деструкторе.
Придётся узнать, что обычные операторы можно реализовать внутри класса, а сдвиги в поток - вне класса потому, что поток - левый операнд. И чтобы это реализовать, придётся одним из нескольких способов приоткрыть private-члены для оператора.
Придётся научиться выделять память так, чтобы при выбрасывании исключения не было утечки памяти.
Ещё в C++ куча способов инициализировать член. Тут и инициализация через равно, через круглые скобки, через фигурные скобки, через каст и оператор присваивания, значения по умолчанию для типа, аргументы по умолчанию, аргументы по умолчанию у класса-родителя. Вместе эти способы рождают множество комбинаций, которые нужно либо учесть в своём коде, либо правильно прочитать в чужом.
Ещё какая-то жопа с компиляцией шаблонов. Проще всё в *.h сплавить.
Кстати, если у шаблонного класса есть шаблонный метод, и это пишется в реализации (как для *.cpp-файла), то это уже без гуглёжки не напишешь, а чужой код - не проверишь.
А если в теле шаблона берётся тип или шаблон через :: из параметра шаблона, то придётся дописать "typename" или "template" перед этой конструкцией, только это не для произвольного выражения работает, придётся разбавлять код тайпдефами.
Описания типы, прости Господи, слизали со сраной сишки. И если типы STL хоть как-то адекватно описываются, то обычный массив константных указателей на функцию уже требует недюжинной нагрузки на мозг или кучи тайпдефов. И это - тривиальщина. Функция, возвращающая указатель на функцию? Придётся гуглить и учить способ чтения сигнатур по спирали. В Haskell те же типы записываются тривиально.
Ко всему этому добавляется куча случаев неопределённого поведения.
C++ - это зековская феня. Чуть что не так - под шконку, ошибся - пидорнули. После пяти лет программирования к этому привыкаешь и получаешь удовольствие, хотя нормальные люди косо смотрят.
И исправить это можно. Даже ECMAScript пошёл по пути исправления.
Ну, вообще-то так и есть. Всё что выше уровнем чем асм считается высокоуровневым языком.
Но удивляет другое -- коммент, начинающийся со слов "как я много раз объяснял", написанный с апломбом, вдруг выходит в плюса...
Но удивляет другое -- коммент, начинающийся со слов "как я много раз объяснял", написанный с апломбом, вдруг выходит в плюса...
Так себе классификация я тебе скажу. Традиционно все языки с ручным управлением памятью считают низкоуровневыми. Кто-то к ним даже языки со статической типизацией, но уже со сборщиком мусора относит. А к высокоуровневым языки где даже типизация динамическая (питон. джс, пхп)
Где ты такую классификацию вычитал? Вот тебе определение с вики, и оно более чем каноничное:
In computer science, a high-level programming language is a programming language with strong abstraction from the details of the computer. In contrast to low-level programming languages, it may use natural language elements, be easier to use, or may automate (or even hide entirely) significant areas of computing systems (e.g. memory management), making the process of developing a program simpler and more understandable than when using a lower-level language. The amount of abstraction provided defines how "high-level" a programming language is.[1].
Прошу заметить, MAY automate, OR hide entirely. Может автоматизировать, может не автоматизировать. Может скрывать, может не скрывать. Это один из параметров, определяющих "высоту" языка. Но это все еще язык высокого уровня, если он абстрагирован от машинных инструкций, что мы и имеем в ЦПП.
In computer science, a high-level programming language is a programming language with strong abstraction from the details of the computer. In contrast to low-level programming languages, it may use natural language elements, be easier to use, or may automate (or even hide entirely) significant areas of computing systems (e.g. memory management), making the process of developing a program simpler and more understandable than when using a lower-level language. The amount of abstraction provided defines how "high-level" a programming language is.[1].
Прошу заметить, MAY automate, OR hide entirely. Может автоматизировать, может не автоматизировать. Может скрывать, может не скрывать. Это один из параметров, определяющих "высоту" языка. Но это все еще язык высокого уровня, если он абстрагирован от машинных инструкций, что мы и имеем в ЦПП.
Определение выше очень абстрактно. И оно вполне вписывается в сказанное мною выше. Все эти пассажи про абстракции и удобство, и natural language elements, easier to use. Ну ты понял. Хотя это целиком и полностью зависит от используемых линеек. В любом случае делить языки на "только ASM низкоуровневый, все остальные высокоуровневые" - не очень разумно, имхо. Можно тогда переименовать "высокоуровневые" на "не ассемблер" )
Ну, так-то в целом все по делу написал же.
Он тебя еще переживет, в ноябре вышла новая версия. https://www.iso.org/standard/72320.html
Это не абсолютное количество, а на каждые 10000 комментов
От авы со Спайдером глаз радуется
Трансметрополитен не забыт
Трансметрополитен не забыт
Хреновая логика и вот почему: Набор статистики судя по всему был устроен так, ищется комментарий где упоминается %lang_name%, в нём ищутся ругательства. И потом вычисляется соотношение "количество ругательств" делить на "количество комментариев с упоминанием %lang_name%". Ответ будет не зависеть от общего количества комментариев.
LustigerSchuler прав, указанная проблема существует. И логика не хреновая.
Чем меньше выборка, тем меньше точность. Скажем, для редкого языка будет 100 комментариев, 10 матерных, для частого языка - 1e6 комментариев и 1e5 матерных. В обоих случаях неуч радостно скажет, что язык на 10% плохой и успокоится. Но в первом случае погрешность, скажем, будет 10%, а во втором - 0.1%. Для первого языка могло с большой вероятностью оказаться, что мы зарегистрировали бы 0% матерных комментариев, если бы зашли на другой аналогичной форум. Для второго языка чуть менее, чем везде было бы около 10% матерных комментариев.
Чем меньше выборка, тем меньше точность. Скажем, для редкого языка будет 100 комментариев, 10 матерных, для частого языка - 1e6 комментариев и 1e5 матерных. В обоих случаях неуч радостно скажет, что язык на 10% плохой и успокоится. Но в первом случае погрешность, скажем, будет 10%, а во втором - 0.1%. Для первого языка могло с большой вероятностью оказаться, что мы зарегистрировали бы 0% матерных комментариев, если бы зашли на другой аналогичной форум. Для второго языка чуть менее, чем везде было бы около 10% матерных комментариев.
Чтобы написать коммент, необходимо залогиниться
