А потом он решил купить сигарет.
08.07.2020, 20:53
Ох уж эти чудеса билдостроения на крестах:
>сначала запустите гребаный симейк чтобы создать солюшен из овер9к разновидностей всевозможных компиляторов
>затем когда эта срань закончит, запустите билд сорс кода, который будет билдится хуй знает сколько времени потому что умники разработчики в соотвествии со всеми правилами элегантного дизайна понатыкали везде кучу темплейтов, инклюдов в стандартные библиотеки, которые раздувают код до сотен тысяч строк, когда ты пользуешься всего-лишь одной функцией из либы
>конечно же сорс код поделен на тысячи компилейшен юнитов каждый из которых будет компилироваться заново, потому что сука потому что.
>под конец ебучий линкер кряхтя пердя и охуевая будет пытаться это говно собрать воедино.
И это все причина почему код на крестах компилится минуты, часы, в охуевших случаях типа хромиума сутки. Просто потому что люди в комитете крестов далеки от реальной разработки, а обычные погромизды долбоёбы, которые следуют по заветам теоретиков, а в итоге получается такое дерьмо. Хотя по факту код пусть даже из миллионов строк не должен компилиться на каком-то среднем текущем процессоре больше 10 сек.
>сначала запустите гребаный симейк чтобы создать солюшен из овер9к разновидностей всевозможных компиляторов
>затем когда эта срань закончит, запустите билд сорс кода, который будет билдится хуй знает сколько времени потому что умники разработчики в соотвествии со всеми правилами элегантного дизайна понатыкали везде кучу темплейтов, инклюдов в стандартные библиотеки, которые раздувают код до сотен тысяч строк, когда ты пользуешься всего-лишь одной функцией из либы
>конечно же сорс код поделен на тысячи компилейшен юнитов каждый из которых будет компилироваться заново, потому что сука потому что.
>под конец ебучий линкер кряхтя пердя и охуевая будет пытаться это говно собрать воедино.
И это все причина почему код на крестах компилится минуты, часы, в охуевших случаях типа хромиума сутки. Просто потому что люди в комитете крестов далеки от реальной разработки, а обычные погромизды долбоёбы, которые следуют по заветам теоретиков, а в итоге получается такое дерьмо. Хотя по факту код пусть даже из миллионов строк не должен компилиться на каком-то среднем текущем процессоре больше 10 сек.
А как делают нетеоретики, расскажи. Пихают всё в один гигантский файл? О да, это же намного лучше.
Комитет как раз и рад бы модули запилить, только в нем есть 100500 компаний с правом вето которым и так норм.
Плюсы как яп конеш помойка, только вот люди на нем пишут не самые тупые. Так что жду рекомендаций, как плюсовики-недолбоёбы пишут.
P.S. Бай зе вей, на картинке - не плюсы, а сишарп.
Комитет как раз и рад бы модули запилить, только в нем есть 100500 компаний с правом вето которым и так норм.
Плюсы как яп конеш помойка, только вот люди на нем пишут не самые тупые. Так что жду рекомендаций, как плюсовики-недолбоёбы пишут.
P.S. Бай зе вей, на картинке - не плюсы, а сишарп.
Да на коре вообще элементарно сделать так чтобы он похожие ошибки вывалил, достаточно чтобы у тебя разъехалась синхронизация между версией sdk в csproj и версиями пакетов sdk из nuget. При переезде с 2.x на 3.x я вдоволь насмотрелся на ошибки в стиле "а я не знаю что такое system.void".
Ну я такое встречал при динамической компиляции netcoreapp приложения из CSharpCodeDomProvider. Как такое получить в студии - не уверен, то думаю что-то связанное с отсутствием нужных версий фреймворка. Но по `System.Void` в предпоследней ошибке язык можно установить однозначно.
>А как делают нетеоретики, расскажи. Пихают всё в один гигантский файл? О да, это же намного лучше.
Почти, другалёк, юнити билд погугли. К сожалению пользуются им в основном в гейдеве, потому что там нужно выжимать максимум производительности. Те же юбики его юзают.
>Комитет как раз и рад бы модули запилить, только в нем есть 100500 компаний с правом вето которым и так норм.
Ну кресты и так на издыхании находятся, пользуются ими просто потому что больше нечем. Когда появится вменяемая альтернатива где будут и вменяемые хай левел абстракции: темплейты, метапрограмминг и т.д. и к лоу левелу не будет закрыт доступ: работа с сырой памятью, возможность встраивать ассембли напрямую, тогда кресты пойдут нахуй далеко и надолго.
>Плюсы как яп конеш помойка, только вот люди на нем пишут не самые тупые. Так что жду рекомендаций, как плюсовики-недолбоёбы пишут.
Дата ориентированный дизайн. Минимум абстракций, никаких иерархий, не каплить дату с функциями. Такое делают к сожалению опять-таки только в гейдеве, где юзерам нужно минимум 60 фпс и приходится выжимать все соки, а не выебываться абстрактными абстракциями и 6-слотовыми наследованиями.
Почти, другалёк, юнити билд погугли. К сожалению пользуются им в основном в гейдеве, потому что там нужно выжимать максимум производительности. Те же юбики его юзают.
>Комитет как раз и рад бы модули запилить, только в нем есть 100500 компаний с правом вето которым и так норм.
Ну кресты и так на издыхании находятся, пользуются ими просто потому что больше нечем. Когда появится вменяемая альтернатива где будут и вменяемые хай левел абстракции: темплейты, метапрограмминг и т.д. и к лоу левелу не будет закрыт доступ: работа с сырой памятью, возможность встраивать ассембли напрямую, тогда кресты пойдут нахуй далеко и надолго.
>Плюсы как яп конеш помойка, только вот люди на нем пишут не самые тупые. Так что жду рекомендаций, как плюсовики-недолбоёбы пишут.
Дата ориентированный дизайн. Минимум абстракций, никаких иерархий, не каплить дату с функциями. Такое делают к сожалению опять-таки только в гейдеве, где юзерам нужно минимум 60 фпс и приходится выжимать все соки, а не выебываться абстрактными абстракциями и 6-слотовыми наследованиями.
А в плюсах разве есть метапрограммирование? По моему, его только планируют ввести.
Имхо, C# движется в хорошем направлении и по моему в нем все есть. Конечно напрямую с памятью проблематично работать, но у меня не возникало такой необходимости. Асм вставки тоже ну что-то ну очень прям экзотическое для этого должно быть...
C# достаточно зрел+ мультиплатформенен, а в .Net Core так вообще не требуется больше иметь на ПК исполняемую среду и можно Standalone компиляцию делать.
Т.е он должен удволитворять 80% все задачи.
Имхо, C# движется в хорошем направлении и по моему в нем все есть. Конечно напрямую с памятью проблематично работать, но у меня не возникало такой необходимости. Асм вставки тоже ну что-то ну очень прям экзотическое для этого должно быть...
C# достаточно зрел+ мультиплатформенен, а в .Net Core так вообще не требуется больше иметь на ПК исполняемую среду и можно Standalone компиляцию делать.
Т.е он должен удволитворять 80% все задачи.
Метапрограммирование это грубо говоря код, который сам пишет код. Ты его хоть на ассамблере написать можешь, другой вопрос насколько он поддерживается средствами языка. Ну а темплейты на крестах это ад и израиль, который не дебажится, генерирует тонну плохо пахнущего кода и очень долго парсится компилятором/невозможно прекомпилировать в принципе. Что в очередной раз подтверждает что коммитет крестов состоит из теоретиков далеких от реальности.
Ага кресты находяться на издыхании, держи в курсе братан. Почти весь вменяемый гейм дев, системные программисты, программисты микросхем и электроники, VR, медицинское оборудование, десктопные приложения, операционики, драйвера и так далее. Здыхают здыхают уже 50 лет здыхают никак здохнуть не могут. Альтернативы вы где а то уже 20 стандарт выходит? Альтернативы вы где а то С/С++ 1 место в рейтинге популярности языков занял.
https://www.tiobe.com/tiobe-index/
https://www.tiobe.com/tiobe-index/
Кодеры такие же, просто требования к качеству софта совсем другие. Например, есть история, что windows 95 и 98 падают ровно через 50 дней ( https://www.cnet.com/news/windows-may-crash-after-49-7-days/ ), И узнали об этом только через 8 лет. А знаешь почему? Потому что ни одна винда ни у кого за 8 лет не смогла столько времени провести без перезагрузок, и люди этот баг не замечали. Вот вам и надежный софт, написанный труЪ сишниками в конце прошлого века.
Поэтому когда тру-сишник не знает, что такое принцип единой ответственности, и лезет из многих потоков мимо буфера потому что "я точно знаю што там а если там не так то виноват Васян который забыл что в этой ситуации в этой функии этот инт не просто инт, а поинтер на вон ту штуку с которой надо что-то сделать", то для меня это не трушность, а глупость.
Ну и наконец, даже если не спорить про тупость кодеров: и что дальше с этим делать? НУ окей, допустим кодеры тупые, они НЕ МОГУТ писать на супер-си, а писать кому-то надо или нет? Вот и придумывают всякие хрусты и жабы, которые не позволяют по ногам стрелять, говорят "а вы тут лок забыли на шаред переменную" и прочие непотребства. Ишь чего придумали, владение, заимствование, лайфтаймы, иммьютабл, набор каких то слов бесполезных, нормальный программист никогда не ошибётся и два раза не напишет фри или не начнёт мутировать из 2 ух потоков данные без синхронизации
Поэтому когда тру-сишник не знает, что такое принцип единой ответственности, и лезет из многих потоков мимо буфера потому что "я точно знаю што там а если там не так то виноват Васян который забыл что в этой ситуации в этой функии этот инт не просто инт, а поинтер на вон ту штуку с которой надо что-то сделать", то для меня это не трушность, а глупость.
Ну и наконец, даже если не спорить про тупость кодеров: и что дальше с этим делать? НУ окей, допустим кодеры тупые, они НЕ МОГУТ писать на супер-си, а писать кому-то надо или нет? Вот и придумывают всякие хрусты и жабы, которые не позволяют по ногам стрелять, говорят "а вы тут лок забыли на шаред переменную" и прочие непотребства. Ишь чего придумали, владение, заимствование, лайфтаймы, иммьютабл, набор каких то слов бесполезных, нормальный программист никогда не ошибётся и два раза не напишет фри или не начнёт мутировать из 2 ух потоков данные без синхронизации
с чего вдруг устаревший ? чистый СИ это:
- код ядра линукс и модулей ядра
- код от которого требуется высокое быстродействие
- код для микроконтроллеров и прочего
те он был и будет всегда, замены ему нет и не будет.
собственно зачем менять то, что отлично работает больше 50ти лет?
- код ядра линукс и модулей ядра
- код от которого требуется высокое быстродействие
- код для микроконтроллеров и прочего
те он был и будет всегда, замены ему нет и не будет.
собственно зачем менять то, что отлично работает больше 50ти лет?
Когда я пришёл на мою нынешнюю работу, там было две больших группы — плюсовики (их было больше) и делфисты, в обоих была огромная кодовая база (у делфистов побольше, ибо фирма начиналась с них). Спустя несколько лет остался только один плюсовые проект и… не осталось программистов. Плюсовики либо поувольнялись по разным причинам, либо перешли на шарп/раст, отказавшись писать на плюсах. Последний живой проект переписывается на юнити для гуи + раст для обслуживания, делфи-проекты тоже переписываются на юнити, иногда на расте, большая часть новых пишется на расте. От поиска новых плюсовиков открестились, потому что их кодовую базу очень сложно поддерживать. Все остальные мелкие направления вымерли.
Плюсы в мире вряд ли вымрут, у них огромная ниша — уже написанный код (+ графические движки), но их вполне могут сильно потеснить в новых проектах.
И не нужно смешивать C/C++, плюсы менее популярны судя по твоему же скрину, а совместимость с С у них не больше, чем в других си-подобных языках.
Плюсы в мире вряд ли вымрут, у них огромная ниша — уже написанный код (+ графические движки), но их вполне могут сильно потеснить в новых проектах.
И не нужно смешивать C/C++, плюсы менее популярны судя по твоему же скрину, а совместимость с С у них не больше, чем в других си-подобных языках.
Вот пишут такие гении как ты это уже 50 лет, уже и новые ниши появились, уже и старый код переписывают, уже там выходит новое обновление в. Net которое окончательно заберет нишу с/с++. Так в чем же дело, почему популярность толькл растет? Старых проэктов стает больше?
net никогда не проектировался как убицца С++, это вообще невозможно для языков с ГЦ.
А вот раст - другое дело. Ну и нужно понимать, что такое убьет - вот убили плюсы сишку? Не, живут себе в узкой нише типа эмбеда и радуются. Но объективно понятно, что сишку выкинули отовсюду, где она была: операционки на них не пишут, только саппортят виндолинухи которые никто никогда конечно не перепишет, прикладной софт не пишут, и так далее. Так же и раст, уже сейчас все HFT биржи пишутся на расте как я знаю, хайлоад веб тоже на нем пишут, не зря майкрософт задонатил разработку actix, ну и так далее. Процесс небыстрый, лет 10 точно займет, может больше, и то в конце концов какая-то доля у плюсов все равно останется: доля легаси. А она в любом языке есть. Вот кто помнит про КОБОЛ? А в ньюджерси вон в этом году искали программиста на него, у них там система поломалась, нужен был человек чтобы починить. Но пусть бросит в меня камень тот, кто считает что кобол не умер.
А вот раст - другое дело. Ну и нужно понимать, что такое убьет - вот убили плюсы сишку? Не, живут себе в узкой нише типа эмбеда и радуются. Но объективно понятно, что сишку выкинули отовсюду, где она была: операционки на них не пишут, только саппортят виндолинухи которые никто никогда конечно не перепишет, прикладной софт не пишут, и так далее. Так же и раст, уже сейчас все HFT биржи пишутся на расте как я знаю, хайлоад веб тоже на нем пишут, не зря майкрософт задонатил разработку actix, ну и так далее. Процесс небыстрый, лет 10 точно займет, может больше, и то в конце концов какая-то доля у плюсов все равно останется: доля легаси. А она в любом языке есть. Вот кто помнит про КОБОЛ? А в ньюджерси вон в этом году искали программиста на него, у них там система поломалась, нужен был человек чтобы починить. Но пусть бросит в меня камень тот, кто считает что кобол не умер.
Не вижу роста популярности плюсов. C чувствует себя хорошо. По тому же TIOBE с 2002 по 2020 C++ упал с 16% до 6%, С# вырос до 5%, C чуть просел с 20% до 18% (вероятно, си исчезнет очень и очень поздно, потому что он уже многие годы своего рода лингва франка), java просела с 26% до 15%.
И хватит писать С/С++, это разные языки, я же не пишу С/Rust. Код плюсов вряд ли когда-нибудь пустят в код линукс, что не похоже на ситуацию великой схожести языков. Да они даже не совместимы между собой! Я перешёл когда-то с плюсов на си, а потом ушёл на раст — так мне писать C++/C/Rust? Gtk живёт со всеми языками в мире и согласии, написан на чистом си, кьют разве что сам с собой играет, поддержка других языков у него отвратительная из-за врождённой плюсовости.
Нишу С (как лингва франка, хотя си этим и не ограничивается) никто не тронет в ближайшие годы, ниши С++ не существует, он старается быть всем, как и многие другие языки.
Ну а «такие гении как ты» твердили, что какая-то джава-выскочка будет даже не замечена плюсами (сейчас же по все рейтингам джава популярнее плюсов, даже не смотря на появление кучи других jvm-языков, потеснивших уже саму джаву), затем в начале нулевых писали, что в геймдеве равных плюсам нету, а потом крайенжин получил части на шарпе, вышел шарповый юнити, на котором сегодня большинство поделок выходят. Или чего ты ждёшь — мгновенного схода на нет плюсов? Они будут жить долго, но их слава с годами меркнет всё сильнее, просто потому что новые языки вытесняют старые, с чем плюсы не смогут бороться, не сломав обратную совместимость, но тогда это уже будут не плюсы.
И C# никогда не стремился отобрать всё у C/C++, он стремился быть более специализированным, как и Java. И Java успеха достигла большего — кровавый энтерпрайз именно с джавой связывают.
И хватит писать С/С++, это разные языки, я же не пишу С/Rust. Код плюсов вряд ли когда-нибудь пустят в код линукс, что не похоже на ситуацию великой схожести языков. Да они даже не совместимы между собой! Я перешёл когда-то с плюсов на си, а потом ушёл на раст — так мне писать C++/C/Rust? Gtk живёт со всеми языками в мире и согласии, написан на чистом си, кьют разве что сам с собой играет, поддержка других языков у него отвратительная из-за врождённой плюсовости.
Нишу С (как лингва франка, хотя си этим и не ограничивается) никто не тронет в ближайшие годы, ниши С++ не существует, он старается быть всем, как и многие другие языки.
Ну а «такие гении как ты» твердили, что какая-то джава-выскочка будет даже не замечена плюсами (сейчас же по все рейтингам джава популярнее плюсов, даже не смотря на появление кучи других jvm-языков, потеснивших уже саму джаву), затем в начале нулевых писали, что в геймдеве равных плюсам нету, а потом крайенжин получил части на шарпе, вышел шарповый юнити, на котором сегодня большинство поделок выходят. Или чего ты ждёшь — мгновенного схода на нет плюсов? Они будут жить долго, но их слава с годами меркнет всё сильнее, просто потому что новые языки вытесняют старые, с чем плюсы не смогут бороться, не сломав обратную совместимость, но тогда это уже будут не плюсы.
И C# никогда не стремился отобрать всё у C/C++, он стремился быть более специализированным, как и Java. И Java успеха достигла большего — кровавый энтерпрайз именно с джавой связывают.
Ты бы нормальный рейтинг взял, а не TIOBE, было бы лучше. Хотя бы stackoverflow survey: https://insights.stackoverflow.com/survey/2019#most-popular-technologies . А то си который популярнее джавы это уже даже не смешно
Говооит взял бы нормальньнвй рейтинг привел мне таблицу с стак оверфлоу за 2019 год? Лол.
А что не так с тем, что я написал ввше? Я написал именно о рейтинге ПОПУЛЯРНОСТИ который основываеться на количестве запросов. Но ладно можем глянуть другие рейтинги IEEE, PYPL, RedMonk и что ты увидишь? Что С/С++ в топе и не опускакться ниже 5 места уже на протяжении многих лет, а если говорить про количество написангого кода на С/С++ то вообще лучше не выебываться.
А что не так с тем, что я написал ввше? Я написал именно о рейтинге ПОПУЛЯРНОСТИ который основываеться на количестве запросов. Но ладно можем глянуть другие рейтинги IEEE, PYPL, RedMonk и что ты увидишь? Что С/С++ в топе и не опускакться ниже 5 места уже на протяжении многих лет, а если говорить про количество написангого кода на С/С++ то вообще лучше не выебываться.
Во-первых за C/C++ любой человек который пишет на них обычно начинает выражаться очень плохими словами. Плюсы да, в топе, а си - отнюдь.
Во-вторых рейтинг TIOBE показывают что люди гуглят. То есть если есть популярная жаба у которой есть нормальная дока и проблемы с которой бывают сравнительно редко, то в рейтинге она будет низко - ну не гуглят люди.
И наоборот, возьмем какой-нибудь VB с 0 использованием, но у которого дохрена проблем и нет документации, в рейтинге будет высоко.
То что рейтинг говно очевидно - ну НЕ МОЖЕТ быть VB выше JS, ну вот вообще никак, даже на другой планете. Это очевидно каждому кто хоть чуть-чуть в теме разработки.
не нравится SO? Ну возьми любой рейтинг, хоть гитхаб, хоть статистику hh/любого другого агрегатора вакансий. Да хоть твой RedMonk на который ты сослался
1 JavaScript
2 Python
2 Java
4 PHP
5 C#
6 C++
7 Ruby
7 CSS
9 TypeScript
9 C
11 Swift
12 Objective-C
13 Scala
13 R
15 Go
15 Shell
17 PowerShell
18 Perl
19 Kotlin
20 Haskell
В это я ещё готов поверить. В си на первом месте и вб выше JS - уж извини, но никак.
Во-вторых рейтинг TIOBE показывают что люди гуглят. То есть если есть популярная жаба у которой есть нормальная дока и проблемы с которой бывают сравнительно редко, то в рейтинге она будет низко - ну не гуглят люди.
И наоборот, возьмем какой-нибудь VB с 0 использованием, но у которого дохрена проблем и нет документации, в рейтинге будет высоко.
То что рейтинг говно очевидно - ну НЕ МОЖЕТ быть VB выше JS, ну вот вообще никак, даже на другой планете. Это очевидно каждому кто хоть чуть-чуть в теме разработки.
не нравится SO? Ну возьми любой рейтинг, хоть гитхаб, хоть статистику hh/любого другого агрегатора вакансий. Да хоть твой RedMonk на который ты сослался
1 JavaScript
2 Python
2 Java
4 PHP
5 C#
6 C++
7 Ruby
7 CSS
9 TypeScript
9 C
11 Swift
12 Objective-C
13 Scala
13 R
15 Go
15 Shell
17 PowerShell
18 Perl
19 Kotlin
20 Haskell
В это я ещё готов поверить. В си на первом месте и вб выше JS - уж извини, но никак.
>Почти весь вменяемый гейм дев
C# Unity
>системные программисты, программисты микросхем и электроники
Полторы позиции в мире.
>VR
C# Unity
>медицинское оборудование
Еще половина позиции в мире.
>десктопные приложения,
Почти никто не пишет на плюсах
>операционики, драйвера и так далее.
Еще полторы позиции в мире
>Альтернативы вы где а то С/С++ 1 место в рейтинге популярности языков занял.
Мммм, как интересно. И что же этот рейтинг популярности обозначает? Особенно Visual Basic и R в первой десятке?
C# Unity
>системные программисты, программисты микросхем и электроники
Полторы позиции в мире.
>VR
C# Unity
>медицинское оборудование
Еще половина позиции в мире.
>десктопные приложения,
Почти никто не пишет на плюсах
>операционики, драйвера и так далее.
Еще полторы позиции в мире
>Альтернативы вы где а то С/С++ 1 место в рейтинге популярности языков занял.
Мммм, как интересно. И что же этот рейтинг популярности обозначает? Особенно Visual Basic и R в первой десятке?
Если ты не погружался в тему, это не значит "полторы позиции". Множество народу пишет огромное количество кода на и на уровне операционных систем, и на уровне специализированного софта типа медицинского и биологического, и требования к качеству там не те, что у веб-макак или в геймдеве, где юзера всё поправят модами.
>Множество народу пишет огромное количество кода на и на уровне операционных систем, и на уровне специализированного софта типа медицинского и биологического
Цифры давай. А то пишет у него огромное количество, а вакансий в 10 раз меньше, чем в геймдеве, и в 150 раз чем у веб-макак.
Цифры давай. А то пишет у него огромное количество, а вакансий в 10 раз меньше, чем в геймдеве, и в 150 раз чем у веб-макак.
> Почти, другалёк, юнити билд погугли. К сожалению пользуются им в основном в гейдеве, потому что там нужно выжимать максимум производительности. Те же юбики его юзают.
Судя по тому, что я читаю, этот юнити билд судя по всему не серебрянная пуля. Например, видимо он не умеет в инкременталку и при изменении одной строчки пересобирает всё приложение. Удачи поработать так с любым крупным приложением, особенно упомянутым тобой хромиумом. Неплохо про минусы тут собрано: http://web.archive.org/web/20161021225056/https://engineering-game-dev.com/2009/12/15/the-evils-of-unity-builds/
> Ну кресты и так на издыхании находятся, пользуются ими просто потому что больше нечем. Когда появится вменяемая альтернатива где будут и вменяемые хай левел абстракции: темплейты, метапрограмминг и т.д. и к лоу левелу не будет закрыт доступ: работа с сырой памятью, возможность встраивать ассембли напрямую, тогда кресты пойдут нахуй далеко и надолго.
У нас 2 микросервиса на расте уже написаны, полёт нормальный.
> Дата ориентированный дизайн. Минимум абстракций, никаких иерархий, не каплить дату с функциями. Такое делают к сожалению опять-таки только в гейдеве, где юзерам нужно минимум 60 фпс и приходится выжимать все соки, а не выебываться абстрактными абстракциями и 6-слотовыми наследованиями.
Если у тебя проблема с абстракциями то тебе в го, там с этим всё хорошо, нет ни абстракций, ни способа их сделать. Лепота.
Не, я согласен, что лишние абстракции копить не стоит, а наследование имплементации не нужно, но обычно люди которые говорят про "лишние" абстракции даже инкапсулировать какой-нибудь filterM не могут, копипасятят каждый раз.
Судя по тому, что я читаю, этот юнити билд судя по всему не серебрянная пуля. Например, видимо он не умеет в инкременталку и при изменении одной строчки пересобирает всё приложение. Удачи поработать так с любым крупным приложением, особенно упомянутым тобой хромиумом. Неплохо про минусы тут собрано: http://web.archive.org/web/20161021225056/https://engineering-game-dev.com/2009/12/15/the-evils-of-unity-builds/
> Ну кресты и так на издыхании находятся, пользуются ими просто потому что больше нечем. Когда появится вменяемая альтернатива где будут и вменяемые хай левел абстракции: темплейты, метапрограмминг и т.д. и к лоу левелу не будет закрыт доступ: работа с сырой памятью, возможность встраивать ассембли напрямую, тогда кресты пойдут нахуй далеко и надолго.
У нас 2 микросервиса на расте уже написаны, полёт нормальный.
> Дата ориентированный дизайн. Минимум абстракций, никаких иерархий, не каплить дату с функциями. Такое делают к сожалению опять-таки только в гейдеве, где юзерам нужно минимум 60 фпс и приходится выжимать все соки, а не выебываться абстрактными абстракциями и 6-слотовыми наследованиями.
Если у тебя проблема с абстракциями то тебе в го, там с этим всё хорошо, нет ни абстракций, ни способа их сделать. Лепота.
Не, я согласен, что лишние абстракции копить не стоит, а наследование имплементации не нужно, но обычно люди которые говорят про "лишние" абстракции даже инкапсулировать какой-нибудь filterM не могут, копипасятят каждый раз.
Дельфи компилировал намного быстрее. По крайней мере когда я им ещё занимался.
"Старые добрые" борланд времена, когда в программирование не понаехала куча айти-макак, которым промыли голову ооп-дизайном. А сейчас имеем с одной стороны либо языки высокого уровня для детского сада: сисярп, жабаскрипт, жава, где детям запрещают работу с памятью, а то не дай бог, да и подальше от того что процессор делает. А с другой стороны франкенштейн в лице крестов, который понатырил кучу идей отовсюду и по сути всё кроме наследия си, на котором был сделан, делает хуево.
Так и живем.
Так и живем.
Дельфи полностью ооп. Собственно говоря борланд ооп ещё в турбо паскаль 5.5 встроил.
> нетеоретики
Как нетеоретик, отвечаю. Во-первых, использовать такие либы только в самом крайнем случае, если без этого никак не обойтись. По возможности вместо тяжелых внешних зависимостей, когда нужна одна функция, либо делать свою реализацию, либо даже тупо вырезать функцию из либы и скопипастить локально - если это поможет убрать тяжелую зависимость. Во-вторых, не использовать системы сборки, которые заставляют пересобирать те модули, которые можно не пересобирать, даже если такие системы супермодерновые и модные. В третьих, изучать документацию на используемые фреймворки и пакеты и отключать сборку опциональных компонентов, а не собирать всё подряд без нужды. В четвертых, использовать оптимизаторы сборки типа METAMODE или ccache, но использовать их с умом. Ну и там по мелочи всякое, типа использовать оперативную память для TMPDIR (ramdisk), в крайнем случае SSD, в самом крайнем случае отдельный HDD, чтобы головки одного диска не перепозиционировались лишний раз; и уж точно при использовании HDD не размещать каталоги исходников и результатов компиляции (объектников, библиотек и исполняемых файлов) на одном HDD.
Короче, не быть тупым кодером и изучать матчасть.
Как нетеоретик, отвечаю. Во-первых, использовать такие либы только в самом крайнем случае, если без этого никак не обойтись. По возможности вместо тяжелых внешних зависимостей, когда нужна одна функция, либо делать свою реализацию, либо даже тупо вырезать функцию из либы и скопипастить локально - если это поможет убрать тяжелую зависимость. Во-вторых, не использовать системы сборки, которые заставляют пересобирать те модули, которые можно не пересобирать, даже если такие системы супермодерновые и модные. В третьих, изучать документацию на используемые фреймворки и пакеты и отключать сборку опциональных компонентов, а не собирать всё подряд без нужды. В четвертых, использовать оптимизаторы сборки типа METAMODE или ccache, но использовать их с умом. Ну и там по мелочи всякое, типа использовать оперативную память для TMPDIR (ramdisk), в крайнем случае SSD, в самом крайнем случае отдельный HDD, чтобы головки одного диска не перепозиционировались лишний раз; и уж точно при использовании HDD не размещать каталоги исходников и результатов компиляции (объектников, библиотек и исполняемых файлов) на одном HDD.
Короче, не быть тупым кодером и изучать матчасть.
1. то есть писать велосипеды когда есть проверенные решения? Хотя в мире плюсов - возможно, не спорю, но в любом языке с нормальным пакетным менеджером - однозначно нет. Особенно если есть LTO которое вырежет всё, что не используется.
2. ну, инкрементные билды обязательно нужны, с этим никто не спорит
3. тоже логично
4. и тут тоже согласен
Но там же по сути речь не про зависимости, а про "абстракций много, файлов много, всё плохо". Много файлов обычно означает хорошую декомпозицию, и это плюс, а не минус. Абстракций - их да, должно быть поменьше, но обычно эту фразу пишут люди которые предпочитают функции по тыщи строк делать, "а чо и так понятно, зато смари как быстра, ЭКОНОМИМ НА ДЖАМПАХ".
2. ну, инкрементные билды обязательно нужны, с этим никто не спорит
3. тоже логично
4. и тут тоже согласен
Но там же по сути речь не про зависимости, а про "абстракций много, файлов много, всё плохо". Много файлов обычно означает хорошую декомпозицию, и это плюс, а не минус. Абстракций - их да, должно быть поменьше, но обычно эту фразу пишут люди которые предпочитают функции по тыщи строк делать, "а чо и так понятно, зато смари как быстра, ЭКОНОМИМ НА ДЖАМПАХ".
Про велосипеды - всё имеет свою цену, и даже использование готовых библиотек имеет свои накладные расходы и если они слишком велики - да, можно и навелосипедить. Не существует абсолютного запрета на велосипеды. LTO не вырежет тебе то, на что есть ссылки в используемых частях библиотеки, например в конструкторе/деструкторе библиотеки. Да, в C на уровне библиотек тоже есть конструкторы.
По моему опыту с LTO проблем вообще нет. Ну то есть например 3мб на приложение это более чем нормально (150мб без LTO).
Согласен, что если в языке нет нормального пакетного менеджера то подключать библиотеку может быть дороже чем её написать самостоятельно, сюда можно и однострочные cfg_if! вспомнить. Но надеюсь с vcpkg у вас с этим станет попроще.
Согласен, что если в языке нет нормального пакетного менеджера то подключать библиотеку может быть дороже чем её написать самостоятельно, сюда можно и однострочные cfg_if! вспомнить. Но надеюсь с vcpkg у вас с этим станет попроще.
1) если тебе не нужны темплейты не юзай их, хочешь для своего конкретного случая? напиши что то свое заточенное под твою задачу, благо с++ предоставляет тебе большой инструментарий.
2)Нигде в правилах элегантного кода не слышал что бы юзали кучу инклюдов и темплейтов. Все как один говорят да блять не юзай тимплейт если он тебе не нужен, не создавать эти уродливые иерархи классов. НЕ ПЛОДИ СУЩНОСТИ СУКА НЕ ПЛОДИ СУЩНОСТИ
3) конечно же сорс код поделен на тысячи компилейшен юнитов , может он как раз специально и поделен что бы заново всю эту хуйню не компилить ?
4)Придумали еще такую штуку как Dll и тебе не нужно ее компилить, да оф кос гиганский проект собирается долго. Но как бы преимущество компилируемого языка не в скорости сборки а в скорости выполнения программы.
5) Ты хоть раз читал C++ ISO? ану что тебе в нем не нравиться? да есть всякое говницо но его стараються убирать и даже в каждом обновлении убирают. И ISO этот как раз классная штука которая делает С++ стабильным.
6) Каким хуем за 10 секунд программный код в миллионы строк должен стать соптимизированным объектным кодом ? ты блять просто посчитай
2)Нигде в правилах элегантного кода не слышал что бы юзали кучу инклюдов и темплейтов. Все как один говорят да блять не юзай тимплейт если он тебе не нужен, не создавать эти уродливые иерархи классов. НЕ ПЛОДИ СУЩНОСТИ СУКА НЕ ПЛОДИ СУЩНОСТИ
3) конечно же сорс код поделен на тысячи компилейшен юнитов , может он как раз специально и поделен что бы заново всю эту хуйню не компилить ?
4)Придумали еще такую штуку как Dll и тебе не нужно ее компилить, да оф кос гиганский проект собирается долго. Но как бы преимущество компилируемого языка не в скорости сборки а в скорости выполнения программы.
5) Ты хоть раз читал C++ ISO? ану что тебе в нем не нравиться? да есть всякое говницо но его стараються убирать и даже в каждом обновлении убирают. И ISO этот как раз классная штука которая делает С++ стабильным.
6) Каким хуем за 10 секунд программный код в миллионы строк должен стать соптимизированным объектным кодом ? ты блять просто посчитай
1) если тебе не нужны темплейты не юзай их, хочешь для своего конкретного случая? напиши что то свое заточенное под твою задачу, благо с++ предоставляет тебе большой инструментарий.
2)Нигде в правилах элегантного кода не слышал что бы юзали кучу инклюдов и темплейтов. Все как один говорят да блять не юзай тимплейт если он тебе не нужен, не создавать эти уродливые иерархи классов. НЕ ПЛОДИ СУЩНОСТИ СУКА НЕ ПЛОДИ СУЩНОСТИ
Объясни это мартыханам, которые без темплейтов и посрать не сядут: нужнапростенькая хэш таблица — темплейт, нужен динамический массив или линкед лист — темплейт.
3) конечно же сорс код поделен на тысячи компилейшен юнитов , может он как раз специально и поделен что бы заново всю эту хуйню не компилить ?
Что значит конечно же, мартыхан. Юнити билд еще раз для тупых повторяю ЮНИТИ БИЛД, чем меньше компилейшен юнитов в сорсе, тем быстрее он будет компилиться. Потому что не надо парсить с нуля каждый юнит.
4)Придумали еще такую штуку как Dll и тебе не нужно ее компилить, да оф кос гиганский проект собирается долго. Но как бы преимущество компилируемого языка не в скорости сборки а в скорости выполнения программы.
Чушь собачья насчет скорости. Сопоставимые проекты по кодо-базе: хромиум и к примеру последний асасин у юбисовта. Хромиум компилится сутки, асасин компилится несколько минут и то это дохуя, но это уже предел для слоупочного с++ компилятора и линкера. Потому что в одном случае делают код люди с мозгами и пониманием аппаратной платформы и дата-ориентированного дизайна, в другом ооп-мартыханы.
>Каким хуем за 10 секунд программный код в миллионы строк должен стать соптимизированным объектным кодом ? ты блять просто посчитай
Что посчитай мартыхан? На современном кукурузене 12-ядерном кернел линупса должен компилиться меньше чем за секунду, в противном случае это мартышкин код.
Ты главную идею не понимаешь, что текущие кододелы выезжают на ахуенной производительности и росте железа, что позволяет писать ультра хуевый и не оптимизированный код. И это плохо я так считаю.
2)Нигде в правилах элегантного кода не слышал что бы юзали кучу инклюдов и темплейтов. Все как один говорят да блять не юзай тимплейт если он тебе не нужен, не создавать эти уродливые иерархи классов. НЕ ПЛОДИ СУЩНОСТИ СУКА НЕ ПЛОДИ СУЩНОСТИ
Объясни это мартыханам, которые без темплейтов и посрать не сядут: нужнапростенькая хэш таблица — темплейт, нужен динамический массив или линкед лист — темплейт.
3) конечно же сорс код поделен на тысячи компилейшен юнитов , может он как раз специально и поделен что бы заново всю эту хуйню не компилить ?
Что значит конечно же, мартыхан. Юнити билд еще раз для тупых повторяю ЮНИТИ БИЛД, чем меньше компилейшен юнитов в сорсе, тем быстрее он будет компилиться. Потому что не надо парсить с нуля каждый юнит.
4)Придумали еще такую штуку как Dll и тебе не нужно ее компилить, да оф кос гиганский проект собирается долго. Но как бы преимущество компилируемого языка не в скорости сборки а в скорости выполнения программы.
Чушь собачья насчет скорости. Сопоставимые проекты по кодо-базе: хромиум и к примеру последний асасин у юбисовта. Хромиум компилится сутки, асасин компилится несколько минут и то это дохуя, но это уже предел для слоупочного с++ компилятора и линкера. Потому что в одном случае делают код люди с мозгами и пониманием аппаратной платформы и дата-ориентированного дизайна, в другом ооп-мартыханы.
>Каким хуем за 10 секунд программный код в миллионы строк должен стать соптимизированным объектным кодом ? ты блять просто посчитай
Что посчитай мартыхан? На современном кукурузене 12-ядерном кернел линупса должен компилиться меньше чем за секунду, в противном случае это мартышкин код.
Ты главную идею не понимаешь, что текущие кододелы выезжают на ахуенной производительности и росте железа, что позволяет писать ультра хуевый и не оптимизированный код. И это плохо я так считаю.
> Объясни это мартыханам, которые без темплейтов и посрать не сядут: нужнапростенькая хэш таблица — темплейт, нужен динамический массив или линкед лист — темплейт.
Ну-ка, объясни, как это сделать. Я на си пишу, где темплейтов нету. Поэтому никаких стандартных контейнеров тоже нету. Ну-ка, расскажи, как мне делать хэш таблицу? Каждый раз руками заново под каждую структуру? На void? На уродливых извращениях с макросами в стиле "struct hash_##_TYPE", что по-сути есть тот же темплейт, только на минималках и под бутиратами.
> Что посчитай мартыхан? На современном кукурузене 12-ядерном кернел линупса должен компилиться меньше чем за секунду, в противном случае это мартышкин код.
Начали за С++ и темплейты, а щас чот к Си пришли. Ну давай, покажи мне пруфы, что код по объему и сложности сопоставимый с кернелом, может скомпилироваться меньше, чем за секунду. Давай, расскажи, если ты такой дохуя умный и не мартыхан, как правильно надо было писать кернел. Кернел пишут далеко не дураки, не макаки-формошлепы на жс. И довольно высокие стандарты, чтобы твой патч приняли. Сам не посылал, но знаю тех, кто разрабатывает драйвера.
Ну-ка, объясни, как это сделать. Я на си пишу, где темплейтов нету. Поэтому никаких стандартных контейнеров тоже нету. Ну-ка, расскажи, как мне делать хэш таблицу? Каждый раз руками заново под каждую структуру? На void? На уродливых извращениях с макросами в стиле "struct hash_##_TYPE", что по-сути есть тот же темплейт, только на минималках и под бутиратами.
> Что посчитай мартыхан? На современном кукурузене 12-ядерном кернел линупса должен компилиться меньше чем за секунду, в противном случае это мартышкин код.
Начали за С++ и темплейты, а щас чот к Си пришли. Ну давай, покажи мне пруфы, что код по объему и сложности сопоставимый с кернелом, может скомпилироваться меньше, чем за секунду. Давай, расскажи, если ты такой дохуя умный и не мартыхан, как правильно надо было писать кернел. Кернел пишут далеко не дураки, не макаки-формошлепы на жс. И довольно высокие стандарты, чтобы твой патч приняли. Сам не посылал, но знаю тех, кто разрабатывает драйвера.
> Поэтому никаких стандартных контейнеров тоже нету. Ну-ка, расскажи, как мне делать хэш таблицу? Каждый раз руками заново под каждую структуру?
О боже мой, ты ещё не открыл для себя готовые библиотеки на C? Libaura, gperf, cmph, glib, libcfu, uthash, Google SparseHash, libthmap, libmba, libmaa, libhash, publib, libcdb, libmowgli-2, htable, libds, pdel - всё это бесплатные и открытые библиотеки с универсальными реализациями для hashmap, выбирай на вкус и под задачу. Есть и в виде h-файлов.
О боже мой, ты ещё не открыл для себя готовые библиотеки на C? Libaura, gperf, cmph, glib, libcfu, uthash, Google SparseHash, libthmap, libmba, libmaa, libhash, publib, libcdb, libmowgli-2, htable, libds, pdel - всё это бесплатные и открытые библиотеки с универсальными реализациями для hashmap, выбирай на вкус и под задачу. Есть и в виде h-файлов.
Берем glib (как пример того, что я знаю).
https://developer.gnome.org/glib/stable/glib-Hash-Tables.html#g-hash-table-insert
И что мы видим?
gboolean
g_hash_table_insert (GHashTable *hash_table,
gpointer key,
gpointer value);
А gpoonter это
typedef void* gpointer;
Что я и говорил: void*.
Ещё работал с https://linux.die.net/man/3/queue, там аналогично.
Щас просматривать все перечисленные имплементации мне лень. Но выше я перечислил все известные мне способы делать контейнеры и обобщенные алгоритмы. Ну ещё типо "дженерики" из С11. Поэтому мой вопрос - знаете ли вы другие способы? Потому что все они уебанские, не мне вам говорить, чем плох void*.
https://developer.gnome.org/glib/stable/glib-Hash-Tables.html#g-hash-table-insert
И что мы видим?
gboolean
g_hash_table_insert (GHashTable *hash_table,
gpointer key,
gpointer value);
А gpoonter это
typedef void* gpointer;
Что я и говорил: void*.
Ещё работал с https://linux.die.net/man/3/queue, там аналогично.
Щас просматривать все перечисленные имплементации мне лень. Но выше я перечислил все известные мне способы делать контейнеры и обобщенные алгоритмы. Ну ещё типо "дженерики" из С11. Поэтому мой вопрос - знаете ли вы другие способы? Потому что все они уебанские, не мне вам говорить, чем плох void*.
Чтобы написать коммент, необходимо залогиниться
