LINUX.ORG.RU

Ушат помоев в сторону крестолюбов

 , , ловите наркомана,


15

14

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

Последние 7 лет я пишу сугубо на C, и только под Linux (да, да -std=gnu99 и accept4, dup3, __attribute__((cleanup(dtor))) и прочие приятности, позволяющие сделать волосы шелковистее на 15.5%) и не понимаю, для чего вообще нужен C++? То, что на сишке делается красиво и элегантно, в крестах напоминает соитие парализованных дцпшников (к сожалению, утерял картинку, но именно этот образ всплывает в голове, когда вижу очередную порцию крестолапши).

Давайте посмотрим на типичного C++ разработчика: он использует STL, boost, многие любят Qt (не только для GUI), якобы чтобы «писать кроссплатформенный код». В итоге болезный не знает током ни WinAPI, ни POSIX — ничерта. Он абсолютно не разбирается, как работает целевая система, для которой пишет код! Крестокодер просто не осознает, какой лютый ужас кроется за его любимыми iostream-ами, какое лютое говно лежит в boost::filesystem::path, насколько убого-низкоуровневым является boost::asio в 2016 году.

Только крестораб может эпично обосраться и просадить производительность, забыв передавать по ссылке параметры для «горячих» функций (то есть, просто забыв написать «&» в нужном месте).

Также эти убогие завистливо смотрят на type inference в языках, проектировавшихся не как «C на стероидах», и в ответ начинают лепить template и auto не к месту, от чего код адово пухнет и даже IDE перестает его понимать.

Серьезно, просто прекратите писать на этом языке. В следующий раз, начиная новый проект, выберите java (щютка)/go/swift/rust/c. Прекратите насиловать труп и отравлять зловонием все вокруг!

Перемещено true_admin из talks

★★★★

Последнее исправление: a1batross (всего исправлений: 2)

C - где надо быстро. Pascal - для научной работы. C# - для всего остального. Другие лежат на кладбище, либо идут туда.

TurboPascal55
()
Ответ на: комментарий от TurboPascal55

Pascal - для научной работы.

День юмора на лоре.

asaw ★★★★★
()
Ответ на: комментарий от alwayslate

О боже, в плюсах как минимум есть деструкторы (RAII) и шаблоны. Да еще довольно там еще чего есть. Откуда столько поехавших людей?

Dudraug ★★★★★
()
Ответ на: комментарий от TurboPascal55

C - где надо быстро

сейчас и С кое где заменяют на GO lang. Пишут высоконагруженные api. можно конечно python + C... ну и Java родненькая и прогретая

Pascal - для научной работы.

вообще-то уже несколько лет как все перешли на питон. и в обучении и в работах.
паскаль уже слишком стар для всего этого. еще вроде R юзают

C# - для всего остального.

тут дело вкуса. зависит от того что вам нужно написать. конечно если вы знаете только C#....

rusich
()
Последнее исправление: rusich (всего исправлений: 1)

vala наше все.

Крестокодер просто не осознает, какой лютый ужас кроется за его любимыми iostream-ами

люто плюсую.

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

cvv ★★★★★
()

21 страница под тупым высером. Это рекорд или тут просто скор набивают?

Deleted
()
Ответ на: комментарий от Midael

Мешок однобуквенных переменных этому ученому

i, j, k хватит всем.

no-such-file ★★★★★
()

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

Winyr
()
Ответ на: комментарий от TurboPascal55

OpenCL - где надо быстро. OpenCL - для научной работы. C++ - для всего остального. Другие лежат на кладбище, либо идут туда.

Починил. Не благодари.

robus ★★★★★
()
Ответ на: комментарий от TurboPascal55

омг. Java лежит на кладбище и на ней совсем не пишут софт для банков. С++ на кладбище, а афтар сего комента нам пишет из браузера написаного на С# Microsoft Internet explorer.

i36_zubov
()
Ответ на: комментарий от i36_zubov

Один знакомы иммигрировал в Швейцарию и учится там на прогера. На явера. Так вот, в Швейцарии ВСЁ на яве. Начиная от банков и кончая софтом для магазинов, мелких фирм, банкоматов, баннеров и тд. Даже на мк яву юзают.

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

SL_RU ★★★★
()
Ответ на: комментарий от SL_RU

Он же пошутил.

ЗЫ Вот эта фирма - http://www.netree.ch/ - делает всё практически исключительно на C#/.NET. Ну и на C++ там тоже кое-что есть (благодаря мне). А основные заказчики у них - как раз образовательные учреждения. Это я к тому, что не стоит всё переобобщать.

asaw ★★★★★
()
Последнее исправление: asaw (всего исправлений: 1)
Ответ на: комментарий от Deleted

21 страница под тупым высером. Это рекорд или тут просто скор набивают?

оба варианта

reprimand ★★★★★
()
Ответ на: комментарий от asaw

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

SL_RU ★★★★
()
Ответ на: комментарий от TurboPascal55

Pascal - для научной работы

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

mbivanyuk ★★★★★
()
Ответ на: комментарий от Dudraug

в плюсах как минимум есть деструкторы (RAII) и шаблоны. Да еще довольно там еще чего есть. Откуда столько поехавших людей?

Тут 95% знают только один язык (или делаю вид, что знают) - тот, что изучали в школе или на первом курсе, и это не C++. Потому C, Java и C# рулят, а плюсы - отстой.

chimera19
()
Ответ на: комментарий от mersinvald

borrow-checker жить не мешает, а помогает, просто некоторые вещи принято делать иначе.

Настолько помогает, что с ним не реализовать двусвязный список. А там, где нужны атомарные переменные так совсем unsafe ад.

Сделали бы borrow-checker опциональным - была бы помощь, а так любой unsafe означает, что borrow-checker не работает.

chimera19
()
Ответ на: комментарий от SL_RU

полагаю, тут есть областная специфика. Я, если честно, (хотя не особо искал) химических числодробилок на яве не встречал. В основном на фортране, иногда на сях/куде.

arcanis ★★★★
()
Ответ на: комментарий от chimera19

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

Можно, используя smart-pointer Rc.

Сделали бы borrow-checker опциональным - была бы помощь
любой unsafe означает, что borrow-checker не работает.

Unsafe блоки — это и есть блоки без borrow-checker. Безопасная абстракция вокруг ансейфа проверяется borrow-checker. Ансейф только чекер и вырубает, все остальные модели языка должны соблюдаться

mersinvald ★★★★★
()
Ответ на: комментарий от mersinvald

Unsafe блоки — это и есть блоки без borrow-checker.

Шта? ШТА!? Никакой ансэйф чекер не вырубает. Не пиши ерунды.

Esper
()
Ответ на: комментарий от Esper

Мне тебя мордой не только в официальную доку, но и в конкретное предложение потыкать? Окей.

This section gives a view of the memory model that all Rust programs must satisfy.
Unsafe code may go above and beyond the borrow checker while still satisfying this model.

mersinvald ★★★★★
()
Ответ на: комментарий от mersinvald

Unsafe code may go above and beyond the borrow checker

Ну да, может. Используя pointer'ы.

Мне тебя мордой не только в официальную доку, но и в конкретное предложение потыкать?

А теперь ткнись мордой в реальность.

Esper
()
Ответ на: комментарий от Esper

Ок, признаю, не распарсил доку. Посыпаю голову пеплом

mersinvald ★★★★★
()
Ответ на: комментарий от mersinvald

Можно, используя smart-pointer Rc.

Дай ссылку на код. Если там содом и гоморра, которую без защиты диссера не разобрать, то не интересно.

chimera19
()
Ответ на: комментарий от chimera19

Сомневаюсь что найду — это не лучшая практика, так как накладывает оверхэд в рантайме на подсчет ссылок.
Если поверишь на слово — не сложнее реализации на shared_ptr в крестах.

mersinvald ★★★★★
()
Последнее исправление: mersinvald (всего исправлений: 1)
Ответ на: комментарий от mersinvald

Если поверишь на слово — не сложнее реализации на shared_ptr в крестах.

Двусвязный список в C++ на shared_ptr... Мосье знает толк в извращениях.

Зачем? Что там с цикличностью взаимосвязей? Как там с глубиной стека при уничтожении больших списков?

eao197 ★★★★★
()
Ответ на: комментарий от mersinvald

Сомневаюсь что найду — это не лучшая практика, так как накладывает оверхэд в рантайме на подсчет ссылок.

Я получил нужную информацию. Так делать можно, но не нужно.

chimera19
()
Ответ на: комментарий от chimera19

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

mersinvald ★★★★★
()
Ответ на: комментарий от eao197

Двусвязный список в C++ на shared_ptr... Мосье знает толк в извращениях.

Точно такое же извращение как список на Rc. Практического смысла ноль, да и мотивация сомнительна.

Впрочем, это уже совсем оффтоп

mersinvald ★★★★★
()
Последнее исправление: mersinvald (всего исправлений: 1)
Ответ на: комментарий от mersinvald

Точно такое же извращение как список на Rc.

Ну так в C++ двусвязный список делается без unsafe и без возни с умными указателями. Если я правильно понимаю, в Rust-е это не получится.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

В C++ всё — unsafe, начнем с этого.
В расте делается абсолютно точно так же на голых указателях, с единственной разницей, что вместо nullptr тут Option::None (оверхед не накладывает, есть специальная оптимизация).
Но все разыменования голых указателей ограничены unsafe {} и обернуты безопасной абстракцией.

mersinvald ★★★★★
()
Последнее исправление: mersinvald (всего исправлений: 1)
Ответ на: комментарий от mersinvald

В C++ всё — unsafe, начнем с этого.

Он таким и задумывался, если что.

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Он таким и задумывался, если что.

Раст тоже не задумывался абсолютно безопасным.

Еще раз: вы придумали какой-то свой раст.
Такая простая структура как вектор тоже реализуется в ансейфе. И дерево.
И в документации это написано и всем известно: через unsafe традиционно делают 2 вещи: FFI и структуры данных, работающие с голой памятью.
Смысл не в том чтобы сделать работу с голой памятью безопасной на 100%, а в том, чтобы ограничить небезопасные куски от безопасной абстракции.

На Rust можно писать эффективный код вообще не используя unsafe, в том же Cargo нет unsafe-блоков, например. А реализация базовых структур данных и умных указателей руками — очень частая задача, видимо, в вашей работе, раз вызывает такие затруднения.

mersinvald ★★★★★
()
Ответ на: комментарий от GoodRiddance

Внезапно, внутри всех сматрпоинтеров unsafe. См. выше.

mersinvald ★★★★★
()
Ответ на: комментарий от mersinvald

Раст тоже не задумывался абсолютно безопасным.

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

Еще раз: вы придумали какой-то свой раст.

С чего бы мне что-то придумывать? Есть тезис, озвученный даже не мной: двусвязный список в Rust не может быть реализован без ухода в unsafe. Вы утверждаете, что этот тезис неверен?

Смысл не в том чтобы сделать работу с голой памятью безопасной на 100%, а в том, чтобы ограничить небезопасные куски от безопасной абстракции.

Как по мне, так это заявление из категории 640Kb RAM хватит всем.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Расскажите это тем, кто декларирует «мы используем Rust чтобы гарантированно не иметь проблем при работе с памятью».

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

Есть тезис, озвученный даже не мной: двусвязный список в Rust не может быть реализован без ухода в unsafe. Вы утверждаете, что этот тезис неверен?

Утверждаю: может.
Если добавить слово «эффективно», то я скажу что я не вижу причин реализовывать его не через ансейф, и это никак не противоречит идиоматике раста.

Как по мне

Как по вам

mersinvald ★★★★★
()
Последнее исправление: mersinvald (всего исправлений: 2)
Ответ на: комментарий от mersinvald

При допущении

Ну т.е. допущения допускаете вы, а трактую неправильно я.

При допущении, что структуры данных и смартпоинтеры, в которых есть ансейф, реализованы верно (а это допущение очень близко к истине)

Ну да, «мой код работает, если в нем нет ошибок» (с).

Утверждаю: может.

Покажите. При этом мы еще специально заглянем в детали реализации, дабы проверить, где же там unsafe прячется.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

в C++ двусвязный список делается без unsafe и без возни с умными указателями.

такая простая и распространенная структура данных, как двусвязный список для Rust-а оказывается ну совсем уж низкоуровневым

Ну и что? Я уже забыл, когда на Си++ я пользовался самодельным списком. В любом языке (кроме, может быть, ассемблера) необходимо использовать парный язык для выражения вещей, невыразимых на основном - ассемблер в Си и Си++, Си в Java, Haskell и прочем. Для Rust такой парный язык - unsafe Rust.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.