Немного статы по Линукс-разработчикам

Можно ссылку?

Можно конечно

в то время как Clear Linux использовали только 4 % из тех, кто принимал участие в этом опросе.

Вот это поворот! А есть данные о том, какой процент участников опроса слышал про Clear Linux?

на втором месте оказался Qt Creator, который набрал 8,7 %.

Рад за разработчиков Qt Creator. Им удалось сделать крутую и быструю IDE для C и C++, которая по той же скорости работы затыкает всякие там CLion, IDEA и прочий хипстерский хайп-набор приложений.

37,6 % использовали Visual Studio Code
Typescript — наименее знакомыми.

Неожиданно.

Им удалось сделать крутую и быструю IDE для C и C++

это был сарказм? большего тормоза в жизни не видела. и ресурсы жрёт как не в себя. лучше вообще без IDE, чем с этой жутью. что касается моего выбора, если вообще нужно IDE для сишечки или плюсов, то это Code::Blocks. он жрёт в сотни раз меньше памяти и пригоден для программирования на чём угодно, так как конфигурируется под любые форматы и любые девелоперские утилиты.

вот да. судя по всему, так как опрос проводился этой компанией, то о нём 99% разработчиков ничего не слышали, так как не знали, что эта компания существует и имеет свой дистрибутив :)

Нет.

Code::Blocks не умеет в нормальную подсветку и дополнение сложного C++ кода, а Qt Creator использует стандартное решение – libclang.

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

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

а пользы от этого ноль

Это экономит время.

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

Никто не отнимает возможность использовать GCC или даже icc, Clang-овский парсер лишь корректно парсит исходник и экономит твоё время. Эти инструменты очень полезны, в том числе и статический анализ на лету, потому что мы, люди, совершаем глупые ошибки, а статический анализатор – ещё один фильтр, который помогает делать код надёжнее и качественнее.

Clang-овский парсер лишь корректно парсит исходник и экономит твоё время.

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

я не вижу экономии времени при печати кода. ты 99% думаешь, читаешь документацию и только один процент времени пишешь код. ну, если не считать отладки. какая тут экономия? к тому же, когда ты пишешь код, ты понимаешь, что ты пишешь. и тебе не нужны подсказки.

существует овердохрена разных парсеров

Верно, но Clang’овский один из лучших. По-крайней мере эти инструменты следуют философии Unix, в отличие от GCC, который монолитная вещь в себе и из которого невозможно* отцепить парсер, чтобы прицепить его к IDE или редактору кода. А в случае с Clang’ом ты используешь его парсер не только для компиляции, но и для подсветки/дополнения/анализа. Переиспользование инструментов это отличная инженерная практика, которой к сожалению, не может похвастаться GCC и другие компиляторы.

ты 99% думаешь, и только один процент времени пишешь код

А где-то есть подтверждение этому соотношению? Лично у меня это не так и инструменты Clang’а помогают хорошо сэкономить мне время.

* - без значительных трудозатрат на переписывания архитектуры GCC.

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

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

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

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

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

в отличие от неведомых libclang

Они стали практически стандартом. P.S. и для Code::Blocks его адаптируют: http://forums.codeblocks.org/index.php/topic,20623.225.html?PHPSESSID=rf7n9d1hceke4isi3dh37vd2i4

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

Если раньше оверхед по порождённым компилятором бинарям действительно был, то теперь всё сравнялось, а где-то Clang показывает и лучшие результаты. И скорость компиляции у него в целом аналогичная (или даже быстрее) чем у GCC, на Phoronix’е были тесты.

Не нужно идеализировать инструменты. Мне всё равно кем они написаны, теоретиками, практиками, геями или вообще коммунистами. Инструмент выполняет свою работу быстро и качественно? Хороший инструмент. Не выполняет свою работу? Полная хрень и в топку его, какими бы хорошими людьми он не был написан.

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

Ты не можешь выдрать лексер или парсер GCC и использовать его в своём редакторе кода.

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

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

Мне всё равно кем они написаны, теоретиками, практиками, геями или вообще коммунистами.

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

У меня Qt Creator не жрет ресурсы. И Code::Blocks тоже не жрёт. У них приблизительно одинаковое быстродействие и они оба написаны на C++, но в Code::Blocks детский парсер, который часто спотыкается на C++.

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

Ну не натягиваются твои слова на наблюдаемую мной реальность. Я не вижу здесь: https://www.phoronix.com/scan.php?page=article&item=gcc9-clang8-hedt&num=2 и в своём опыте взаимодействия с Clang ту жуткую неэффективность, о которой ты говоришь.

То что Clang существует и развивается это просто отлично. Именно благодаря и вопреки его созданию GCC да и C++ начали развиваться и конкурировать. Именно конкуренция подстёгивает развитие и качество компиляторов.

Стоит вспомнить третью ветку GCC и четвёрку в начале. Стагнация, застой и уныние, прямо как при Брежневе.

У них приблизительно одинаковое быстродействие

вот нет. и даже сравнивать нельзя. особенно на больших проектах. я бы никогда не стала юзать Qt Creator по своему почину, но в одной компании, где я работала, его использовали другие разработчики. при том, что тогда у меня на машине было 32 гига памяти и мощнейший по тем временам проц, но креакл сжирал всё. вообще всё. это были просто эпические тормоза. так что я редактировала код в Code::Blocks.

Стагнация, застой и уныние

компиляторы - это не макаковеб. там не надо каждый день новые свистоперделки приделывать. там главное надёжность и оптимизация. и я пока не вижу никакой пользы в нынешнем «развитии» плюсов. там какую-то плесень в стандарт тащат. это типичная ИБД. но ИБД в стандартах - это очень, очень плохо. собственно, поэтому я в последние годы больше на чистой сишечке пишу. плюсы постепенно становятся хипстерским говнецом. конечно, можно не юзать свистоперделки. но всё равно пованивает.

при том, что тогда у меня на машине было 32 гига памяти и мощнейший по тем временам проц

У Qt Creator были подобные проблемы в самом начале перехода на Clang, сейчас их нету. Да и вообще Clang для парсинга представления кода в Qt Creator стал включен по умолчанию примерно год назад или даже менее, то этого там был такой же детский самописный парсер как в Code::Blocks.

там не надо каждый день новые свистоперделки приделывать. там главное надёжность и оптимизация. и я пока не вижу никакой пользы в нынешнем «развитии» плюсов.

Так там и оптимизации вносят, а не только новые свистоперделки. Из последнего что я помню – возможность хранения небольших строк без выделения памяти, SSO – https://blogs.msmvps.com/gdicanio/2016/11/17/the-small-string-optimization/

Благодаря этой оптимизации даже старый код, собранный новый компилятором вроде GCC 7.x, показывает неплохой прирост производительности в программах, где множество подобных объектов. И таких микрооптимизаций и улучшений море. Комитет не зря ест свой хлеб.

возможность хранения небольших строк без выделения памяти

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

Этот вариант оптимизации строк внесён в GCC и Clang.

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

Да пусть растёт и эволюционирует. Если бы разработчики постоянно думали об уязвимостях, никто бы не написал и строчки кода.

а надо думать! :) вот пусть лучше ни строчки кода без думания про уязвимости, чем апдейты каждый день, а потом всемирный обосрамс. вообще, надо думать в первую очередь о резонности (и разумный минимализм всегда хорош). а во вторую очередь - о безопасности. а уже потом всё прочее. это студент может сначала делать, а потом думать. опытный разработчик всегда сначала думает.

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

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

Вот как раз Clang/LLVM и представляет собой подобие KISS и стройную архитектуру, приятную глазу инженера.

Ты можешь модули Clang/LLVM заюзать для своих нужд по отдельности, при этом сохраняется замечательное свойство переиспользуемости. Именно поэтому на бекенде LLVM базируется огромная куча языков и технологий разной степени применимости и специализации, начиная каким-нибудь банальным Rust и заканчивая LLVMPipe. А фронтенд Clang’а сейчас использует куча IDE и редакторов. Куда уж ещё больше модульности?

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

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

тут зло не в самом проекте. он есть, кто-то даже его использует, и хрен с ним. меня бы это нисколько не волновало, но он порождает много нехороших последствий и тащит в программирование макак. а вот это реальное зло. сложность gcc не давала свободы макакам. это не было сделано умышленно. но это было барьером для отсечения неликвида. и он ограждал программирование от ламеров и недоумков. сейчас вся эта шушара полезла в «тоже программисты». и это очень сильно отражается на общем состоянии софта в мире. софт на 90% состоит из говнокода. и я наблюдаю этот тренд много лет и он мне не нравится.

Они стали практически стандартом.

Практически стандартом для IDE стал LSP - language server protocol.

https://langserver.org

Это для мультиязычных.

P.S. В Qt Creator внедряют LSP.

В Qt Creator внедряют LSP.

Вот и я об этом

Насколько я помню только IntelliJ принципиально отказалась от LSP.

Насколько я помню только IntelliJ принципиально отказалась от LSP.

У них там слишком сложная собственная система, хотя тот же статический анализ через libclang они внедрили.

Компиляторы: GCC использовали 56,3 %, а Clang 11,1 %.

А под линукс есть ещё какие-то (немаргинальные) компиляторы Си/Си++? Чем тогда пользуются остальные?

Есть icc от Intel и несколько небольших компиляторов C. Сомневаюсь, что ими кто-то активно пользуется, так как Clang и GCC стремительно вырвались вперёд в поддержке новых стандартов и платформ.

и пригоден для программирования на чём угодно, так как конфигурируется под любые форматы и любые девелоперские утилиты

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

Насколько я помню только IntelliJ принципиально отказалась от LSP.

Для них свой велосипед – вопрос выживания. Если везде будет одинаковые возможности, то не будет никакого смысла покупать идею.

Так о чём и речь. Я ж специально уточнил - не маргинальные компиляторы. icc, lcc и прочие под это определение не подходят.

icc больше исследовательский проект, вот как Haskell, то бишь не совсем маргинальщина и опрос этот от команды Intel Clear Linux, поэтому они могли часто его использовать.

lcc это для нашего Эльбруса что ли?

Если тебя удивило куда делись ещё 40% компиляторов, то это могут быть rustc или javac, в ОП-посте же не сказано что именно компиляторы для C/C++.

глазу оно, может, и приятно, но факт что ресурс жрёт неприемлемо

Тесты Phoronix’а по ссылке выше и мои личные ощущения это не подтверждают. Сегодня он не лучше и не хуже, но зато удобнее.

но он порождает много нехороших последствий и тащит в программирование макак. а вот это реальное зло.

Не думаю, что Clang притащил в программирование макак. Макаки и макикий софт находятся уровнем повыше.

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

Это палка о двух концах. Из-за сложности и архитектурных недостатков GCC от него отказались Apple, *BSD, Google, Intel, AMD – все они сегодня представляют тулчейны на Clang/LLVM. А это потеря квалифицированных и ценнейших специалистов, которые раньше сидели на жирных зарплатах в этих компаниях и коммитили в компилятор GCC.

lcc

Не, Local C Compiler

Если тебя удивило куда делись ещё 40% компиляторов, то это могут быть rustc или javac

Тогда это идиотская подача материала и манипуляция общественным мнением. Например: 80 процентов программистов использует С#, 5% F#. А остальные пишут не под платформу .net, но про это явно не сказано, а красивые цифры есть.

Ссылки на оригинал исследования в треде я так и не нашёл, делал вывод по кускам перевода.

Не, Local C Compiler

Я про него даже не слышал. А у Эльбруса тоже lcc, закрытый, фронтенд которого они покупают у европейцев или американцев EDG, а бэкенд (типа LLVM) под свою архитектуру и проц пилят сами. Было бы круто, если бы они на Clang перешли, но судя по всему вряд ли перейдут.

делал вывод по кускам перевода

Ну или перевод такой, да.

48,5 % опрошенных использовали Firefox, при этом пользователей Chrome было всего 30,1 %.

Так вот кто те все адекватные люди!

48,5 % опрошенных использовали Firefox, при этом пользователей Chrome было всего 30,1 %.

А я уже начал думать что я маргинал, а оказывается я в тренде!

Для них свой велосипед – вопрос выживания. Если везде будет одинаковые возможности, то не будет никакого смысла покупать идею.

Да, им VS Code подпортил малину и продолжает портить.

Интересно WebStorm кто-то покупает?

то это Code::Blocks

там кнопки вперёд-назад уже появились?

а тебе что нужно? это и есть главная задача IDE.

они там были. Alt+что-то там. я их не использую и не помню наизусть.

PgUp, PgDown?