Насколько разобщены сообщества?

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

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

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

Видел хоть одного такого?

Если шутки в сторону – то да, видел.

Обычно это или люди хорошо за 40, имеющие диплом, скажем, лингвиста и знающие 5 языков «свободно» (в дополнение к мату, русскому и английскому) и ещё пять на уровне «lleva mi cuerpo a mi tierra natal».

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

Короче, непросто всё.

Ты бы поосторожнее с утверждениями, компания то публичная

Ну, это была фигура речи. Эпитет не про половую принадлежность, а про качество кода («две радуги вот этому господину»). На самом деле – разумеется, не берём, потому что тупо нет.

Кроме того, я сам гей, мне такие шутки можно.

на самом деле, ничего не имею против геев или негров (мне же с ними не спать, а работать) или против аутистов (зато они молчат и не мешают). но вот что плюсы пошли по дорожке скатывания вниз - это, увы, факт. а раз жаба и ко уже напоролись на это, то эта тенденция даже более глобальна, чем я предполагала. грабли готовы, надо только наступать снова и снова. и потом будут ходить на собеседования жуткие говнокодеры. уже сейчас в плюсах есть «программисты на кутэ». б*ть, у меня слов приличных нет, люди прямо заявляют, что они программируют «не на C++, а на Qt». и я это наблюдаю на разных форумах уже несколько лет. и дальше будет хуже. формошлёпы, копипастеры, спецЫалисты одного фреймворка, нажиматели кнопки «скомпилировать». на фоне этого зоопарка индусы ещё покажутся сеньорами девелопмента.

А весь опенсорс С++ софт для конкретного линуксового дистра разве не одним компилятором собирается?

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

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

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

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

Про красно-черное могут не знать легко. Для их задач достаточно абстракции TreeMap, даже не дерева в чистом виде, а его главного применения - сортированого словаря. И является ли это внутри Red-black, AVL или еще какая-то штука - не так важно.

В прессе работает все не так. Не важно что ты хотел сказать. Важно как это можно перекрутить

Мне не очень понятно, в чем проблема. Если есть условно код на С++98 и код на С++17, то тут вот такие варианты:

1) обе части собираются компилятором с поддержкой С++17;

2) от части на С++17 отказываются в пользу аналога на С++98 и обе части собираются компилятором с поддержкой только С++98;

3) часть на С++17 переписывается на С++98 и обе части собираются компилятором с поддержкой только С++98;

4) часть на С++98 переписывается (зачем-то) на С++17 и обе части собираются компилятором с поддержкой С++17.

И так для любого компилируемого ЯП с более-менее продолжительной историей.

Они намекают на три вещи

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

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

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

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

Они почти так и делают, просто в пределах одного компилятора. Но никто не запрещает тебе закуклиться, выставить "-std=с++98" и игнорировать код, написанный не по стандарту С++98.

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

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

Они и работают. В комитете стандартизации C++ есть в т. ч. и разработчики из Game-индустрии, где C++ основной ЯП для движков.

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

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

на самом деле, ничего не имею против геев или негров (мне же с ними не спать, а работать)

Ну как бы да.

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

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

Снижение издержек = снижение порога вхождения, индусский код и адаптация инструментов с целью, чтобы допускаемые ошибки меньше сказывались на работоспособности продукта. 30 лет назад цена ошибки была высока – решение падало с SIGSEGV, и, в лучшем случае, клиент заливал core к тебе на FTP. В худшем – Ariane 5 падала на старте. Или кто-то платил своей жизнью.

Сейчас клиенту показывают красивое окошко с рюшечками, градиентами и стектрейсом – и решение через пень-колоду продолжает работать дальше. «В Новом Году мы исправим это патчем».

Здесь я бы сделал два вывода:

1. Ответственное отношение к работе мы наблюдаем там, где цена ошибки по-прежнему измеряется человеческими жизнями.
2. К сожалению, то, что мы наблюдаем в индустрии, – это ровно то же самое, что мы видим, например, в образовании. Это тупо отражение человеческого общества. Гауссоида с её пиком и «крыльями».

Кто вливает средства в язык, тот его и танцует. А эта индустрия для C++ сегодня одна из самых больших, если не самая большая.

Откуда у тебя столько высокомерия? Прямо осаждают тебя некомпетентные маками пишущие тебе негодный компилятор, а ты то знаешь как правильно

Это тупо отражение человеческого общества.

ну да. не поспоришь. и это печально.

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

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

а это не форма. это содержимое их... кхм... черепной коробки. кстати, вот это и есть эталонная макака.

ну да. не поспоришь. и это печально.

Печально другое. Жизнь слишком коротка, чтобы успеть и дождаться, когда общество в целом «вырастет» и преодолеет те детские проблемы, которые для условного Алана Тьюринга уже неактуальны.

Что ж, по крайней мере, ты в определённой степени можешь влиять на это общество. Учить подрастающее поколение, например.

Тебе понравится вот эта статья: http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/

Чуваки перелезли со Scala на Go, потому что в команде было несколько любителей Scalaz, которые писали такую адову функциональщину с монадами и чёртом в ступе, что остальные участники забега тупо перестали понимать их код.

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

Я работал в индустрии на Scala. Это одно из правил там, бить лопатой по пальцам при первом хреноморфизме. Нужно пользоваться умеренно функциональным кодом - функции высшего порядка над коллекциями, комбинирование Futures, разумная иммутабельность.

Scalaz, cats - это все для борща. На своем гитхабе - пожалуйста, экспериментируйте. В продакшн коде желательно выкашивать линтером

На своем гитхабе - пожалуйста, экспериментируйте.

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

Спасибо, интересный опыт.

Я бы сказал, что код на Kotlin сам по себе порой бывает сложен для понимания, без привлечения ArrowKt (аналог cats и scalaz).

И это при том, что Kotlin — это такой «лайтовый» вариант Scala.

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

Как сделаны case class, как сделаны implicits (например для thread pools), как поля имеют скрытые геттеры и сеттеры всегда, par/seq, lazy, cake-pattern, как хорошо интегрируется Akka. Вот такого рода вещи.

А борщееды берут проблемы хаскелля, которых нету в Scala, и решают методами хаскелля, poorly.

Scala - *ML-family, не хаскелль. Там все делается без приседаний с утяжелениями. Если надо - через императивный for-loop.

ArrowKt (аналог cats и scalaz).

И до Котлина добрались

Учить подрастающее поколение, например.

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

успеть и дождаться, когда общество в целом «вырастет» и преодолеет те детские проблемы

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

Одно другому не мешает. Одни запиливают ЯП под лозунгом «как кресты, только лучше», другие вносят «радикальные улучшения» в стандарты под влиянием первых. И под влиянием других ЯП, чтобы было фичасто, не хуже чем у других. А то, что из этого пластилина в итоге можно только макет говна в натуральную величину слепить - это уже никого, по-видимому, не беспокоит. Зато код такой, что брейнфак бледнеет, любо-дорого посмотреть.

плюсую :)

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

Там не только одни они же сидят. Но и куча заскорузлых академиков, которые сопротивляются любым изменениям, которые вносят в C++.

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

Зачем, когда все мейнстримные движки вроде Unity, Unreal Engine, Source 2, CryEngine уже на C++, неплохо работают и приносят кучу $$$? Им проще продавить этой кучей своё виденье, чем переписывать всё на какие-то свои корпоративные язычки, да ещё пилить потом компиляторы этих язычков под кучу платформ и архитектур.

Я имел в виду, что если какие-то новые ЯП претендуют на замену (хотя бы в будущем) С++ , почему бы в разработке этого нового ЯП не принять самое активнейшее участие корифеям С++ . Как пример привел Александреску, который работает над D. Но это только один пример, и видимо, исключение. А так все «кулики» на своих «болотах» сидят.

Я имел в виду, что если какие-то новые ЯП претендуют на замену (хотя бы в будущем) С++ , почему бы в разработке этого нового ЯП не принять самое активнейшее участие корифеям С++

А так все «кулики» на своих «болотах» сидят.

А зачем они, собственно, будут пилить сук, на котором они сидят?

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

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

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

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

а ты такой умный, опенсорцем не пользуешься, дистрибутив свой сам написал, по «гайдлайнам», небось? ты вообще хоть один более-менее крупный проект сам писал или хотя бы собирал и патчил? а то тут страна советов, блин. давай, внедри гайдлайны во все написанные за последние лет 30 проекты. отличная идея. осталось только реализовать. только не забудь: с каждым новым стандартом от бешеного принтера твои гайдлайны идут... в общем, идут далеко.

Да, а теперь boost который тебе когда-то нравился, стал playground для будущих стандартов. В него засылают код только для того, чтобы потом протолкнуть его в стандарт.

Очень много библиотек из boost просто стали частью STL.

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

внедри гайдлайны во все написанные за последние лет 30 проекты

зачем во все и за 30 лет? Нужно только то что используется. На счет сборки дистрибутива - а кто говорил, что это просто, из зоопарка собирать хор? Я же говорю, если у тебя нет административного или финансового контроля над другими проектами, и тебе надо их всех в одной системе интегрировать в не слишком уродливом виде, то таки да, это геморрой. Но такова судьба опенсорсников. Но даже над тем же дистрибутивом типа убунту работает не один человек. Что касается проприетарных проектов - конечно, они используют и опенсорс. А если пилить напильником слишком много надо, то не используется.

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

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

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

и никто практически это не использовал. и вот нахрена это в стандарте?

Орнул с противоречия. Того то и не пользовали

бешеный принтер не разбирает, проприетарщина или нет. он просто рушит совместимости, автоматизацию сборок и тестов, и создаёт геморрой на ровном месте

«бешеный принтер» не лезет к тебе в билд-сервер менять версию компилятора. Так же как авторы опенсорсных проектов не навязывают тебе новые версии своих творений

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

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

проприетарщину вообще-то и на gcc и на clang тоже пилят. Чего там такого нужно покупать? и на вполне бесплатных IDE (даже на vim, помилуй иисусе христе)