Частота использования ругательных слов в отношении языков программирования на реддите за 2018 год
Подробнее
mathematics visualbasic haskell rust clojure programming matlab lua swift scala objectivée golang perl lisp esharp sql epp python ruby java javascript php TTT IE ~1~1 r _r r f I I r W 1 T 1 E 1 r I I I I I I W 1 E 1 E 0 I , ,1 100 150 200 contains word / 10000 comments I I crap 1^ fuck I I hate [ZZ1 shit 50 250 300
geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,it-юмор,javascript,php,Это не шутка
Еще на тему
![» 4 in l <- false Programmer Memes @iammemeloper Without a doubt, the best programming language 11:09 PM -Sep28, 2023 121.6K ¡ews » let l = [1,2,3,4] <- undefined » 0 in l <- true » "0" in l <- true](http://img0.reactor.cc/pics/thumbnail/post-5649316.jpg "» 4 in l <- false Programmer Memes @iammemeloper Without a doubt, the best programming language 11:09 PM -Sep28, 2023 121.6K ¡ews » let l = [1,2,3,4] <- undefined » 0 in l <- true » \"0\" in l <- true")
В плане синтаксиса С++ в общем-то ничего особенного по сравнению с любым другим современным языком. Разница находится снаружи. Когда ты пишешь на каком-нибудь managed-говне, всё что тебя заботит - это твоя собственная прога, а все техники оптимизации заключаются в том, чтобы запускать сборщик мусора пореже. Программиста на С++ заботит не только собственная прога, а то, чтобы получить именно на выхлопе наиболее быстро выполняющийся на железе код. Для этого нужно знать особенности работы железа, как ядра обмениваются кэшированными данными чтобы гонять твоё даже однопоточное приложение на разных ядрах, как читается и алигнится память, как минимально ветвить программу чтобы конвейер проца не простаивал, и выхватывал максимальное опережение чтобы данные были готовы к моменту выполнения, где разместить барьеры памяти, чтобы синхронизация кэша с памятью проходила максимально гладко и быстро, и прочие выкрутасы, благодаря которым код на С++ железо жамкает резвее, как бы managed-говны с виртуальными машинами не пыжились. Всё это заставляет специалиста по плюсам знать не только железные дела, но и разбираться в тонкостях ОБВМ того, кто этот код генерирует - компилятора, и писать код не для людей, а для компилятора, подстраивая программу под его внутренний мир с целью заставить его сгенерить то что нужно для наискорейшего выполнения железом.
tl;dr По вхождению плюсы не сложнее любого другого языка, но труден на профессиональном уровне - мастер до-диеза печётся только о своём коде, в то время как мастеру плюсов приходится знать внутренний мир железа и ублажать компилятор, получая в качестве вознаграждения код, который способен работать до 40 раз быстрее полного аналога на до-диезе за счёт срезания железных углов, что и продолжает обеспечивать плюсам место под солнцем в нише продуктов требующих высокой оптимизации.
А это так, утренняя разминка.
но зачем?
По вхождению плюсы не сложнее любого другого языка, но труден на профессиональном уровне - мастер до-диеза печётся только о своём коде, в то время как мастеру плюсов приходится заходить в каждый топик о программировании на любом ресурсе и ублажать своё ЧСВ.
Свободного времени у профессионала по возне с низким уровнем становится всё больше - можно писать длинные портянки в интернетах.
А вообще, у меня лично, психологическая травма, после того как я стал гуглить, как же передать по ссылке в какой-либо метод двумерный массив произвольной длины (cpp 98). Увиденное не развидеть.
С++ легаси... где вы его находите? Сколько лет работаю, а ни одного прям легаси легаси ни разу не встретил. С++ в принципе не майнтенабелен, поэтому легаси проекты на нём просто не живут. А суржиком пишут там, где нет стандартиста, способного вкатить нерадивым суржикописцам двести кубиков последнего стандарта.
Делфи имхо был мертворождённым, но из-за богатой практики некрофилии поцкаля в отечественных вузах, его труп некоторое время ходил и ел порядочным людям моск. После чего собственный раздувающийся рантайм погубил и его тоже.
> как же передать по ссылке в какой-либо метод двумерный массив произвольной длины (cpp 98)
Оборачиваешь в класс, передаёшь ссылку на класс. А если есть криворукие, то вообще закрыть нахуй прямой доступ к данным без особой надобности. Я лично в дизайне интерфейсов придерживаюсь правила, что ввод от живого человека будет совершенно произвольным, и возможность прицелиться в ногу нужно отключить by design.
Кстати делфи я привёл как пример языка, который не ебанутый. Довольно простой и понятный. А не как пример офигенного продакшн решения. Как пример что те же самые задачи можно решать на языках, спецификация на которые меньше размера видимой части вселенной.
> Оборачиваешь в класс, передаёшь ссылку на класс
Да, я в итоге всё обернул в struct и таскал этот struct туда-сюда. Для моих говно-нужд хватало.
Ситуация примерно десятилетней давности. Сейчас делфятина это вот как раз Ъ-легаси, а С++ регулярно обновляющий стандарт современный язык.
> Кстати делфи я привёл как пример языка, который не ебанутый. Довольно простой и понятный. А не как пример офигенного продакшн решения. Как пример что те же самые задачи можно решать на языках, спецификация на которые меньше размера видимой части вселенной.
Зачем приводить мёртворождённое говно? Язык нужно выбирать под задачу, это так, но если в задаче производительность или железные ограничения стоят первой или второй строчкой, то у тебя нихуя нету выбора.
Поставь себя на место ньюфага. Несмотря на то, что появились вкусные новые штуки, старые некуда не делись. И работать с ними всё равно придётся. И спрашивать с тебя их будут. Полжизни будешь язык учить.
> Зачем приводить мёртворождённое говно?
Трудный ты. Я тебе в пример привожу не язык+экосистему, а именно язык. Т.е именно подход. Я тоже не люблю Delphi. И я знаю что он сдох. Ну почти сдох. Я блин не об этом же пишу. А о том, что он простой и умеет почти всё тоже самое. Он яркий пример того, что дело не в задачах, дело в спецификациях и тех кто их пишет. Ну и в легаси, конечно.
> "у тебя нихуя нет выбора"
По сути это главный аргумент за CPP. Почти единственный. Что в прочем сам язык не красит.
Ты опять же не в теме. Список депрекейтов на каждую новую версию стандарата весьма красноречив.
> По сути это главный аргумент за CPP. Почти единственный. Что в прочем сам язык не красит.
Зато весомый. Погляди на ААА проекты с бюджетами. Они могут позволить себе любых специалистов на любом языке, и руководит ими обычно не сова-эффективный-менеджер. Тем не менее, они выбирают С++.
ебеные числодробилки в игры не добавляют, какие-то супер-пупер вычисления тоже не часто встретишь. меняется только графоний, который задействует gpu. задачи плюс-минус сравнимые. а требования и по опере и по процу растут ровно так же, как и везде.
> возможность прицелиться в ногу нужно отключить by design
ничего на напутал? :)
правильно чувак говорит, легаси. берем книжку времен расцвета плюсов и смотрим хотя бы на хелло ворлд, и берем новую книжку. в старой будет или сишный принтф, который небезопасен, или иостримы, которые тормозные пиздец и 40к строчек темплейтной магии тянут :) для хелло ворлда это конеш не критично, но зачем сразу привыкать к устаревшим методикам? и поэтому в новой книжке будет что-то другое. если вспомнили про юникод, то и вообще сторонняя либа.
в языке большинство исходных техник давно устарели, но не были выкинуты, и прогер вынужден помнить, где там грабли зарыты.
Но C и C++ тянут обратную совместимость настолько, насколько это возможно.
Разработка на C/C++ слишком дорога, компиляторы языков с GC производят такой же быстрый код, последний аргумент - совместимость со старым кодом - убрали.
Выходит, C и C++ не нужны?
Прежний подход ушёл в прошлое, теперь либо ты компилишь старым компилятором (dynamic linking никто не отменял), либо обновляешься и убираешь старьё из кода.
> Разработка на C/C++ слишком дорога
Тем не менее всё ААА выбирает С++ (не очень люблю когда очень разные языки С и С++ упоминают вместе, а Линус за это так вообще нахуй посылает).
> компиляторы языков с GC производят такой же быстрый код
Ну-ну, мечтатели. То-то в ААА видимо совы-эффективные-менеджеры выбирают С++, если есть такие же быстрые альтернативы... нет, пока что манагед-говны даже не близко, и скорее всего никогда не будут близко к написанному грамотным человеком С++ коду.
> последний аргумент - совместимость со старым кодом
не помню чтобы это когда-то было аргументом в принципе.
> Выходит, C и C++ не нужны?
Дуракам они определённо не нужны, дураки в них стреляют себе в ногу.
Секретную гравицапу для арабских шейхов может прямо в машинных кодах пишут, и что?
Ниша C/C++ всё меньше и меньше. Платят не за знание многостраничного стандарта, а за работающую программу.
Только дурак хвалится тем, что виртуозно уворачивается от старого ружья, которое сам крутит в руках, когда можно взять самонаводящиеся ракеты и все проблемы победить.
А дураки продолжают петь про сужающуюся нишу, в которую вот-вот попадут их ракеты.
В науке (по крайней мере, в этой стране) не так много программистов, как хотелось бы. Зарплаты не те. Нельзя позволить просирать ресурсы на борьбу с C++. Медленно, но переходят на адекватные языки, на тот же python. А там уже куча готовых библиотек с C++ внутри. Или cython, если того мало. Разумеется, людей на разработку научных библиотек на C++ для python требуется намного меньше, чем требовалось бы, если бы все продолжали писать на C/C++.
до C++11 вообще нельзя было нормально передать как надо значение заранее неизвестного типа. Значение либо копировалось лишний раз, либо бралась ссылка на не лежащее нигде значение, и код не работал.
Далеко не всем это нужно.
Мне кажется для многих доменов лучше освободить разработчика от железных вопросов. Например, та же связка C#+Unity3d в геймдеве кажется фантастически удобной.
В силу простоты освоения многие любители пробуют себя именно на Unity. Но на Unity пишутся также и ААА-проекты, и интересные инди-проекты.
То что всё самое сложно написали за тебя, оставив тебя скриптовать сверху, причём на жабаскрипте, не отменяет глубокой зависимости от С++.
Что не отменяет того, что и C++ есть свои задачи.
2) Инъекция в виртуальную машину с последующим хаком вообще всего что на ней бегает всяко лучше, да.
Щас работаю в области высокопроизводительных вычислений и пишу на ебучем фортране (потому что все пишут на нем). Те моменты, когда удается поработать с плюсами, воспринимаются как благословение божье
В петлю не лезешь? )
тащемта, чем больше у тебя метаданных о коде, и том, как он выполняется - тем больше простора для оптимизаций.
В C# наследоваться можно от 1 класса и множества интерфейсов => не так все плохо будет.
Если просадки производительности и есть, то они не значительные. То, что ты описал может быть критично для контроллеров, но там пишут на Си. Так что нужны пруфы.
Это как раз те оптимизации, которые НЕВОЗМОЖНЫ при применении особо хитрожопой абстракции. Потому идея в следующем - можно абстрагировать вычислительно сложные задачи - но по возможности стоит избегать абстрагирования мелких вычислительных ядер. Именно это и затрудняет разработку высокпроизводительного софта.
Оплатить такие хотелки не каждый может, далеко не каждый. И количество таких проектов пренебрежимо мало.
С другой стороны, вон фейсбук перешёл с похапе на машинно-генерируемый перевод похапе на С. Производительность выросла на 33%.
Язык вырвиглазный по сравнению с C# и не пытается от этого уйти. Достаточно посмотреть, как выглядят указатели на функции в C# и C++ или сравнить дженерики.
>Всё это заставляет специалиста по плюсам знать не только железные дела, но и разбираться в тонкостях ОБВМ того, кто этот код >генерирует - компилятора, и писать код не для людей, а для компилятора, подстраивая программу под его внутренний мир с >целью заставить его сгенерить то что нужно для наискорейшего выполнения железом.
Преждевременная оптимизация корень всех бед. В итоге получается вырвиглазных несопровождаемый код. В книге "Совершенный код" говорится, что сначало нужно получить рабочую программу, а потом если она не соответствует требованиям производительности, то производить микро-оптимизации. Возможно, нужно лишь 1 цикл поправить и все будет в шоколаде. Для этого существует много современных профилировщиков.
>managed-говны
Не понимаю твоей желчи в сторону управляемых языков программирования. Да, может быть они и жрут памяти немного больше, чем при ручном управлении, но память сейчас дешевая. Алгоритмы сборки мусора сейчас совершеннее, чем были ранее => не вызывают заметных для пользователя тормозов.
Зачем знать тонкости работы двигателя, если я могу взять машину и поехать на ней?
Ну не скажи. Они работают быстро, пока памяти много. Чем ближе ты к пределу, тем жоще тормоза. Причём формально программа ещё работает, а по факту 95+% времени пытается освободить ну хоть что-нибудь. Лучше бы просто сдохла и перезапустилась, всё равно большая часть её памяти это утечки. Причём это касается любых языков с GC. Хоть JS, хоть C#.
Расскажи это энтерпрайз Java системам которые работают с 20-40 гигами оперативы. За последние годы разработки GC шагнули далеко вперед и значительная часть работы происходит параллельно с работой программы
Но сказать то ты что хотел? Что мне такого нужно рассказать кровавому ынтерпрайзу, чего они сами не знают?
И пассаж про 20-40 GiB ОЗУ я не понял. Прямо совсем. Поменяй 20 на 2 или на 200. Что изменилось? Ты о чём?)
Твои знания по плюсам устарели, теперь везде автовыведение типа не хуже шарпа, а std::function и лямбды давно заменили С-подобные указатели на функции.
> Преждевременная оптимизация корень всех бед. В итоге получается вырвиглазных несопровождаемый код. В книге "Совершенный код" говорится, что сначало нужно получить рабочую программу, а потом если она не соответствует требованиям производительности, то производить микро-оптимизации. Возможно, нужно лишь 1 цикл поправить и все будет в шоколаде. Для этого существует много современных профилировщиков.
В С++, по крайней мере в высокооптимизированной нише, подход к разработке иной, чем для бизнес-приложений где безбажность важнее производительности. Там сперва строится прототип, и по его скелету проектируется готовый продукт вместе с оптимизацией сразу. И сразу же настраивается на дейли билде сравнение затрачиваемого времени на рендер кадра с профилировщиком, с автоматическим репортом, и сравнивается с другими продуктами на этом же движке, чтобы работало "не хуже чем Х", разбор полётов "почему тормоза" и оптимизация будут идти на любом этапе - производительность обычно важнее багов, кроме самых критических.
> Не понимаю твоей желчи в сторону управляемых языков программирования.
Однажды меня наняли загнать С#-проект в телефоны. В не самые новые телефоны. Количество говна которое я отгрёб от managed-памяти всё время желающей откусить больше чем есть, и запуском сборщика мусора в самые неподходящие моменты на моно 2.0 - ты себе просто не представляешь. Лучше ручками сделаю, чем ещё раз полагаться на моно...
Тип легко выводит IDE с подсказкой, никакой необходимости его описывать нет.
по данным Benchmarks Game от команды Debian - в среднем преимущество примерно двухкратное, что в общем-то тоже не мало
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/csharpcore-gpp.html
если это долгоживущий сервис - то после прогрева
2-3 раза от силы, если бездумно хуячить, не задумываясь о производительности на обоих языках. если задумываться - там уже не разы будут, а проценты.
40 раз это разве что gpu заюзать, но это уже не к языкам относится, ничто не мешает заюзать gpu хоть их шарпа, хоть из питона.
не надо забывать, что плюсы компиляются ровно так, как написаны, а шарп джитится после накопления статистики. со временем код может перекомпиляться несколько раз и стать даже быстрее плюсового за счёт более агрессивного инлайна и выпиливания ненужных кусков.
в этом плане что-то кардинально лучшее - это только собрать 1 раз софтину, погонять ее, собрать статистику, потом сунуть в компилятор для оптимизаций. но в плюсах такого никогда не будет. возможно, будет в d, или в русте.
а также не нужно забывать, что современное железо гораздо сложнее, чем многие о нем думают, от балды из общих соображений что-то там прикидывать, какой код будет быстрее - прокатывает всё реже и реже. надо мерить. что в плюсах, что в шарпе - везде надо.
Ну и конечно то, что ты не понимаешь современное железо - не значит что оно слишком сложное.
лучшие инженеры планеты, разрабы компиляторов, им говорят, не сможешь ты, дубина, угадать, как поведет себя компилятор и процессор, я сам не смогу, меряй, не выёбывайся - нет блять, всё равно пойдут лабать говно наобум, но при этом в полной уверенности в своей илитарности
Не зря Мейерс специально пишет книги тупо о том, как писать на 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. Может автоматизировать, может не автоматизировать. Может скрывать, может не скрывать. Это один из параметров, определяющих "высоту" языка. Но это все еще язык высокого уровня, если он абстрагирован от машинных инструкций, что мы и имеем в ЦПП.
"Уровневость" языка нужна только затем чтобы сказать, например, что какой-то X-lang ниже уровнем чем, например, Python, и, может быть, выше чем C, и одно это позволяет неплохо понять за X-lang и его место среди других языков.
А называть свою личную интерпретацию тем же термином, и говорить, что это традиционно... Ну ты понел.
Трансметрополитен не забыт
Чем меньше выборка, тем меньше точность. Скажем, для редкого языка будет 100 комментариев, 10 матерных, для частого языка - 1e6 комментариев и 1e5 матерных. В обоих случаях неуч радостно скажет, что язык на 10% плохой и успокоится. Но в первом случае погрешность, скажем, будет 10%, а во втором - 0.1%. Для первого языка могло с большой вероятностью оказаться, что мы зарегистрировали бы 0% матерных комментариев, если бы зашли на другой аналогичной форум. Для второго языка чуть менее, чем везде было бы около 10% матерных комментариев.
Надо бы курнуть то же, что авторы комикса.