Об светлом будущем C++

Стыд и срам!
Топик занимает последнее место в топе наиболее флудливых.

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

В реализациях HFT динамически-типизированным языкам места нет. Ну вот вообще. В разработке реализаций HFT (например, когда вы с вычислительными моделями экспериментируете) может быть что угодно: хоть Lisp, хоть Excel с VBA, хоть MathCAD.

«Разработка железа» — это слишком общий термин, там много всего.

Разработка компиляторов. Если вы пишете компилятор для своего собственного языка, ваш компилятор будет использоваться только вами и у вас нет жестких требований (по быстродействию, по ресурсоемкости, по объемам перевариваемых объемов кода), то вы его можете делать на чем угодно. C++ тут явно не лучший выбор. Но и у Lisp-а здесь будут конкуренты в виде OCaml-а с Haskell-ем как минимум.

Опять же, разговор начался с вычислительной математики. Для вас она, явно, ограничена небольшим подразделом того, с чем вам довелось столкнуться в HFT (это было что-то из статистики, тер.вера, Марковских процессов?).

Ну возьмите задачи из других областей. Например, расчет прочности конструкций. Тоже скажете, что Lisp со своей нотацией там удобнее привычной математической? И что какой-нибудь CL будет заруливать C++ по скорости вычислений?

Я лисп (CL) не знал на момент трудоустройства.

Да судя по тому, что вы говорите, вы и сейчас знаете разве что какое-то подмножество C++ и Lisp. Были бы у вас в багаже и другие безопасные языки с GC, может вы бы и на мир смотрели шире.

Кроме того, вы опять демонстрируете уровень Ыксперта. Что за «сложные проекты»? В какой области?

Вот ClickHouse или MongoBD — это сложные проекты? В их реализации тот же CL выгоднее использовать?

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

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

В мире C++ сейчас есть очень яркий аналогичный пример: маленькая компания Think-Cell, которая непропорционально сильно известна в C++ных кругах. Там в точности тоже самое, но с поправкой на то, что вместо Lisp-а лидер команды использует C++.

Из того, что вы рассказали, очевидно, что для вашего спектра задач C++ не подходил (вроде как вы не в начале-середине 1990-х все это делали). Ну так нормальные люди и не говорят о том, что C++ должен использоваться везде. А вот почему вы не смотрели в сторону OCaml/Clean/Haskell или даже Scala — вот это интересный вопрос.

Ну понятно, что в вашем свете это ошибка выжившего.

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

Вот основатель вашего стартапа явно был из таких. И к себе на борт он взял таких же.

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

Я не смог распарсить написанное.

Вывод типов в современном мире используется повсеместно.

Чистота функций и иммутабельность сейчас осознается как полезные качества очень многими. Проблема в том, что изрядное количество мейнстримовых языков (Java, C#, Python, Ruby и пр.) появилось тогда, когда на это мало обращали внимания. Там даже константности нормальной нет.

Тем не менее, этот опыт учитывают. В Rust-е иммутабельность по умолчанию. В D есть и иммутабельность и чистые функции.

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

Так что не понял, что вы хотели сказать.

Например, нормальным выводом типов

Вывод типов в современном мире используется повсеместно.

Вы что ли про auto из C++ или var из Java и C#? Это не вывод типов*. А ничего другого в Top 20 TIOBE (https://www.tiobe.com/tiobe-index/) я не вижу.

Чистота функций и иммутабельность сейчас осознается как полезные качества очень многими. Проблема в том, что изрядное количество мейнстримовых языков (Java, C#, Python, Ruby и пр.) появилось тогда, когда на это мало обращали внимания. Там даже константности нормальной нет.

Тем не менее, этот опыт учитывают. В Rust-е иммутабельность по умолчанию. В D есть и иммутабельность и чистые функции.

Зачем вы мне рассказываете, что есть в D и Rust? Это не мейнстрим. Чистоты и иммутабельности в мейнстриме (пока) нет. Смотрите тот же TOP 20.

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

Так что не понял, что вы хотели сказать.

Давайте я ещё раз повторю, с чего начал.

Были бы у Лиспа вообще и у s-expression в частности какие-то серьезные преимущества, весь мир бы ими пользовался. Но нет.

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

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

Из того, что Лиспом и s-expression «не пользуется весь мир», вы сделали вывод, что у них нет «серьезных преимущества». Я привёл ещё несколько важных концепций из мира ЯП, которыми также «не пользуется весь мир». Следует ли отсюда, что у них нет тоже серьезных преимуществ? Если по-вашему ответ тоже «да», то вопросов больше нет. Если же вы с этим не согласны, то и про преимущества Лиспа вы не можете рассуждать с точки зрения массовости использования. Так понятнее?


*Да, я знаю, что в википедии написано иное. Нет, википедия это не авторитетный источник. Если хотите, можем начать этот терминологический спор, но лучше не надо :)

Извините, как только кто-то пытается апеллировать к TIOBE, то он сразу же идет в сад.

Туда же идут апелляции к мейнстриму, ТОП-20 и пр. критериям популярности. Поскольку как только вы это делаете, все разговоры про якобы имеющиеся преимущества Лиспа и s-expression сразу же прекращаются ввиду практически полного отсутствия оных в дикой природе.

Ваши пояснения картину не прояснили.

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

А есть вещи, которые, напротив, себя не зарекомендовали. И от использования которых постепенно отказываются. И, опять же, это хорошо видно на отрезке в 20-30 лет.

Вот Лисп из этой категории. И это временем доказано. Последствия чего мы и наблюдаем в современном мейнстриме.

Не нравится TIOBE? Без проблем. Тогда чем вы можете обосновать вашу фразу «весь мир не пользуется Лисп»? Вы же опираетесь на какой-то рейтинг или статистику? Приводите её, посмотрим, как там обстоят дела.

Или это ваше субъективное оценочное суждение, чем мир пользуется, а чем — нет? Согласно тому же TIOBE мир по-прежнему пользуется Лиспом больше, чем Rust. Приводите другую статистику, потому что ваше личное мироощущение насчёт того, как выглядит мейнстрим, обсуждать, в общем-то, не конструктивно.

Тогда чем вы можете обосновать вашу фразу «весь мир не пользуется Лисп»?

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

Во-вторых, вы можете обратиться к любым источникам, которые дадут вам _кажущуюся вам_ объективную картинку: индексам TIOBE, langpop, исследованиям IEEE, спискам вакансий и пр. Если вы где-нибудь увидите хоть сколько нибудь значимое присутствие Lisp-а, то дайте знать.

Или эта ваше субъективное оценочное суждение, чем мир пользуется, а чем — нет?

Конечно мое и субъективное.

мир по-прежнему пользуется Лиспом больше, чем Rust.

Простите, но языковые пуристы очень часто ведут себя и высказываются как идиоты. Вы еще сравните количество строк кода, которые были написаны на всех диалектах Lisp-а за почти 60 лет существования этой группы языков с количеством строк на Rust-е, написанных за последние 3 года.

Это бессмысленно.

Осмысленным было бы попытаться дать ответ: почему появившийся недавно современный язык, который заслуженно вызывает к себе интерес и который дает надежду на то, что в мире нативного программирования появится что-то получше C++, вообще не имеет никакого отношения к Лиспу?

Во-вторых, вы можете обратиться к любым источникам, которые дадут вам _кажущуюся вам_ объективную картинку: индексам TIOBE, langpop, исследованиям IEEE, спискам вакансий и пр. Если вы где-нибудь увидите хоть сколько нибудь значимое присутствие Lisp-а, то дайте знать.

Так я и обратился, к TIOBE. Там Лисп, Rust и D занимают сравнимые доли. При этом Лисп вы мейнстримом не считаете, а Rust и D — считаете, я правильно понимаю? И говорите, что TIOBE плохой. Да ради бога, давайте вашу статистику.

Простите, но языковые пуристы очень часто ведут себя и высказываются как идиоты. Вы еще сравните количество строк кода, которые были написаны на всех диалектах Lisp-а за почти 60 лет существования этой группы языков с количеством строк на Rust-е, написанных за последние 3 года.

Да ради бога [2]. Как мне сравнивать-то, чтобы вас устроило? :-) Есть ли вообще хоть один рейтинг, где Rust и D существенно обгонят Clojure, Scheme, Racket?..

Осмысленным было бы попытаться дать ответ: почему появившийся недавно современный язык, который заслуженно вызывает к себе интерес и который дает надежду на то, что в мире нативного программирования появится что-то получше C++, вообще не имеет никакого отношения к Лиспу?

Странный вопрос, честно говоря. Однако... Rust-овские макросы идеологически растут из Лиспа, разве нет?

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

1. Индекс TIOBE — это никакой не измеритель популярности или востребованности. Как только кто-то пытается его в таком качестве использовать — он сразу же расписывается в профнепригодности.

Если бы вы сослались на исследования IEEE или на статистику GitHub-а, то это было бы уже другое дело. Но вы написали именно про TIOBE. И это уже говорит о том, что общение с вами, скорее всего бесперспективно.

2. Вы пытаетесь убрать из разговора Rust и D. Мол, это не мейнстрим. Так же вы пытаетесь утверждать, что в мейнстриме нет вывода типов. Но при этом хотите говорить про Lisp. Которого в мейнстриме вообще нет от слова совсем.

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

Есть ли вообще хоть один рейтинг, где Rust и D существенно обгонят Clojure, Scheme, Racket?..

С ручника снимитесь, хватит тормозить. Покажите рейтинг, где Lisp-оподобные языки заметны на фоне C++, Java, C#, Python, JavaScript, Ruby.

Rust и D — это современное развитие именно таких языков, а не Lisp.

Странный вопрос, честно говоря.

Если тупить как вы, то да, странный.

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

Простите мне мой французский

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

UPD: Раз уж по делу разговора всё равно не будет, то напоследок замечу очень любопытный факт. Выше по треду вы сильно возбудились и праведно негодовали, когда юзер mv сказал, что «не понимающим запись (+ x y) место в биореакторе».

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

Презабавно, как первое и второе могут происходить из одной головушки, м-да.

mv производит впечатление человека с сильно завышенным на почве изучения Лиспа ЧСВ.

Вы же просто воруете мое время упражняясь в схоластике. Умным такое поведение назвать не могу при всем желании.

«не понимающим запись (+ x y) место в биореакторе».

Истины ради, было: «не может переучиться». Не понимают все, кто ещё не сталкивался и не разбирался, что к чему. Это не страшно.

Презабавно, как первое и второе могут происходить из одной головушки, м-да.

Тред осеннего обострения же... ;)

mv производит впечатление человека с сильно завышенным на почве изучения Лиспа ЧСВ.

Почему лиспа? Может, чего-то другого? Или не моё ЧСВ завышено, а ваше занижено? Что там TIOBE говорит про среднее ЧСВ по индустрии? ;)

Rust-овские макросы идеологически растут из Лиспа, разве нет?

Под «Лиспом» обычно понимается Common Lisp. Нет, макросы Rust растут не отуда - для начала, они гигиенические. При желании, можно сказать, что они растут из Scheme, но макропроцессоров существует столько, что ты устанешь отслеживать их родословную. Лично я ставлю на p4 или ddx, поскольку Грейдон Хоар - старый окамльщик,

Почему лиспа?

Ну вы же рассказываете про свой переход с C++ на Lisp. А не на OCaml или Haskell.

Впрочем:

Ну, может ML, но я на нём не писал, практически.

Можно предположить, что вы так и остались с багажом в C/C++ и Lisp.

Или не моё ЧСВ завышено, а ваше занижено?

«Заниженное ЧСВ»? Да это комплимент.

Что там TIOBE говорит про среднее ЧСВ по индустрии?

Евгений Ваганович?

Ну вы же рассказываете про свой переход с C++ на Lisp. А не на OCaml или Haskell.

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

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

Можно предположить, что вы так и остались с багажом в C/C++ и Lisp.

Не, индустриальная кривая вернула в русло чистого Си. Темы интересные, оплата высокая, конкуренции нет. Но опыт работы с лиспом оставил самые положительные результаты профессионального развития.

«Заниженное ЧСВ»? Да это комплимент.

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

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

Эм, именно поэтому оно сейчас есть в куче языков, включая раст? Без метапрограммирования некоторые вещи просто не сделать безопасно, например, printf. В окамле, например, тип printf зависит от строки (то есть

printf "%s %f"

printf "%d"

Что до безопасности самого метапрограммирования, то макросы могут быть типизированы и впролне безомасны, например:

http://okmij.org/ftp/ML/MetaOCaml.html

К слову о регекспах:

https://www.youtube.com/watch?v=QM3W36COnE4

Понятно, что считать шаблоны нормальным метапрограммированием нельзя, ибо полный ад и вообще accidental, но тем не менее статический regex возвращающий конкретный тип безопаснее динамических вариантов, как и статическая проверка sql типов и всего такого.

Эм, именно поэтому оно сейчас есть в куче языков, включая раст?

Можно список? Ну чтобы представить размер этой самой кучи. Ну и масштабы востребованности языков из нее.

А то есть ощущение, что мы будем говорить не только и не столько о Rust-е, сколько об OCaml-е каком-нибудь. Или Clojure.

По поводу Rust-а в этом треде уже tailgunner свои опасения высказывал.

Без метапрограммирования некоторые вещи просто не сделать безопасно, например, printf

В C++ной fmtlib как-то умудрились.

Rust-овские макросы идеологически растут из Лиспа, разве нет?

Под «Лиспом» обычно понимается Common Lisp. Нет, макросы Rust растут не отуда - для начала, они гигиенические. При желании, можно сказать, что они растут из Scheme

Ок, насчёт «Лиспа» принято. Если конкретнее, то я читал, что макросы Rust вдохновлены Racket.

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

Что ж, нужно обратиться к самим растовцам с этим вопросом. Есть список статей, который is a reading list of material relevant to Rust. It includes prior research that has - at one time or another - influenced the design of Rust, as well as publications about Rust.

Там есть статья «Macros that work together», которая описывает макросы в Racket. Dixi.

В C++ной fmtlib как-то умудрились.

Она не выводит тип, насколько я знаю, просто дергает перегруженный <<. Чтоб вывести тип аргументов в зависимости от значения строки, тебе нужно парсить строку в компайл тайме, а это уже метапрограммирование, либо программирование с зависимыми типами. Выбирай способ по нраву, называется.

Можно список? Ну чтобы представить размер этой самой кучи.

rust, лиспы, кресты (метаклассы и шаблоны), пистон (метаклассы), скала, разные мл, окамл, ast трансформеры в руби. Да все, по сути, пользуются какими-то ast преобразователями, сейчас уже почти нет живых языков без метапрограммирования. Ну жаба разве что.

Ну у меня много других воодушевляющих успехов было

Ну т.е. диагноз был поставлен точно. И пациента переход с C++ на Lisp в анамнезе. Неподготовленная психика не выдержала.

Ну я не знаю, откуда такая реакция тогда на притеснения языка программирования?

Вокруг C++ слишком много мифов и городских легенд. А это не может не сказываться на том, где и как язык используется и, главное, не используется. Когда от C++ отказываются даже там, где его использование оправдано, просто на основании вот таких вот «ыкспертных» заявлений:

Я программировал на C++ и на Лиспе, и всего лишь утверждаю, что сложные проекты на Лиспе проще писать.

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

Про Scala не в курсах. Когда я с ней развлекался, там метапрограммирования не было еще.

В C++ метаклассов еще нет. Метапрограммирование на шаблонах... Когда в больших дозах — спасибо, не нужно.

С Ruby много упражнялся в этом деле (но без AST-трансформаций (ссылочками на оные поделитесь?)). Поначалу прикольно. Потом хрен разберешься. Даже в своем коде. Так что тут как и с C++: когда в больших дозах, то спасибо, не нужно. В Python-е, насколько я понимаю, тоже самое.

Кроме Java есть еще и C# в мейнстриме. Там как с метапрограммированием?

Ну т.е. диагноз был поставлен точно. И пациента переход с C++ на Lisp в анамнезе. Неподготовленная психика не выдержала.

Простите покороно, что я всё туда же, с ЧСВ, но позволяет ли вам квалификация диагнозы ставить?

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

Ну вот попробуют сами, и у них появится опыт. И они смогут отделить правду от вымысла. И смогут делать заявления на основании собственного опыта. А те, кто не попробовал, будут опирать свои заявления не знамо на что. «Лучше C++ ничего нет, потому что я ничего другого не пробовал». Ну ок, чё...

Когда в больших дозах — спасибо, не нужно.

Ну речь опять же не про не нужно, понятно, что шаблоны говно и лучше иметь полноценные зависимые типы (как в F* [1] или Idris), либо на худой конец мощную (и желательно типизированную) систему кодогенерации (как в metaocaml). Речь о то, что есть класс задач, которые безопасно без кодогенерации/зависимых типов не решить. Ну в частности что-то подобное [2] просто не напишешь без этого

[1] https://github.com/FStarLang/FStar/blob/master/examples/printf/SimplePrintf.fst

[2] https://github.com/mfp/ocaml-sqlexpr

ruby: http://www.recursion.org/query-parser/

Простите покороно, что я всё туда же, с ЧСВ, но позволяет ли вам квалификация диагнозы ставить?

Вы же не ставите свою квалификацию под сомнения, когда говорите, что Лисп лучше для решения сложных задач, чем C++.

Вот и я этого не делаю, когда вижу очередного упоротого лиспера на просторах Интернета.

Ну вот попробуют сами, и у них появится опыт.

Молодежь не будет пробовать то, у чего есть репутация старого и ненужного дерьма.

Мы вот, например, в начале обучения, от Fortran-а шарахались. Именно потому, что репутация у него была соответствующая. Тем не менее, в своих областях Fortran до сих пор заруливает все, включая и C++.

«Лучше C++ ничего нет, потому что я ничего другого не пробовал». Ну ок, чё...

Так это вы кроме C, C++ и Lisp-а ничего не пробовали. Понятно, что на таком фоне Lisp будет сверкать. Особенно там, где смысла использовать C++ нет в принципе.

Ну речь опять же не про не нужно, понятно, что шаблоны говно

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

Речь о то, что есть класс задач, которые безопасно без кодогенерации/зависимых типов не решить.

Тут есть два важных момента.

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

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

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

Тут, к сожалению, не так однозначно.

Особенно с учетом снижения общего уровня квалификации на фоне повального желания «войти-в-ойти».

Так что прошу понять меня правильно. Я не категорический противник метапрограммирования. Но считаю, что это слишком большая пушка. И, следовательно, опасная.

За ссылку на Ruby-новый случай спасибо.

Вы же не ставите свою квалификацию под сомнения, когда говорите, что Лисп лучше для решения сложных задач, чем C++.

Основываясь сугубо на собственном опыте, на собственном! Который у меня есть, в отличие от...

Молодежь не будет пробовать то, у чего есть репутация старого и ненужного дерьма. Мы вот, например, в начале обучения, от Fortran-а шарахались. Именно потому, что репутация у него была соответствующая. Тем не менее, в своих областях Fortran до сих пор заруливает все, включая и C++.

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

По наличию большого количества негативных высказываний («дерьмо» и всё такое) тоже. Но вам, кажется, на это уже указывали несколько раз в этом треде?

Так это вы кроме C, C++ и Lisp-а ничего не пробовали. Понятно, что на таком фоне Lisp будет сверкать. Особенно там, где смысла использовать C++ нет в принципе.

Ой, я чего только не пробовал. Реакция на бОльшую часть из опробованных ЯВУ, правда, была: «в лиспе лучше сделано», но были и обратные случаи. И делаю выводы. Мы же профессионалы, мы должны быть объективны?

Например, я не буду больше high level synthesis писать на лиспе. 10 лет назад выбора не было, и надо было быстренько написать самому, а сейчас есть.

Вы же не ставите свою квалификацию под сомнения, когда говорите, что Лисп лучше для решения сложных задач, чем C++.

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

Да-да-да, только вам известна истинная сила Lisp-а и только вы имеете представление о чем-то за пределами C++. А ваши собеседники, как вам думается, только в рамках C++ и мыслят.

Посему еще раз вынужден повторить: мозг не жмет?

Да-да-да, только вам известна истинная сила Lisp-а и только вы имеете представление о чем-то за пределами C++. А ваши собеседники, как вам думается, только в рамках C++ и мыслят. Посему еще раз вынужден повторить: мозг не жмет?

Нет. Чтобы жал, надо доказать своё несомненное превосходство на одном поле. А мы на нём даже встретиться не можем. У вас эмпирические представления о лиспе, а у меня практические. Вот как тут спорить?

У вас эмпирические представления о лиспе, а у меня практические.

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

Вот как тут спорить?

Спорить можно о том, применим ли какой-то язык в какой-то конкретной задаче. Но когда пациент говорит просто что на Lisp-е сложные задачи решаются проще, чем на C++, даже без обозначения предметной области, то диагноз очевиден.

Ну и еще дополню. Лет 10 назад, а может уже и больше, довелось сделать специальный DSL для того, чтобы вручить его DevOps-ам. И там было две проблемы. Во-первых, нужно было его сделать быстро и времени/ресурсов на разработку подобия нормального языка не было. Во-вторых, конструкции этого DSL должны быть расширяемыми.

Поэтому был сделан в чем-то похожий на Lisp (точнее на такой его своеобразный потомок, как Curl). И конструкции if там выглядели как-то так:

{if {and {some_predicate ...} {another_predicate ...}}
   {then ...}
   {else {if {or {some_predicate ...} {and {predicate ...} {predicate ...}}}
            {then ...}
         }
   }
}

Да, люди освоили. И пользовались затем долго (может быть даже до сих пор). И скрипты такого объема и сложности делали, что и представить себе невозможно было.

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

Вокруг C++ слишком много мифов и городских легенд. А это не может не сказываться на том, где и как язык используется и, главное, не используется. Когда от C++ отказываются даже там, где его использование оправдано, просто на основании вот таких вот «ыкспертных» заявлений

А что с C++ так все плохо? Странно читать об этом от плюсовщика, который и выступает еще на конференциях.

Знаю один замечательный магазинчик по книгам у нас в городе. Там мало литературы по программированию как везде, но по С++ больше всего книг, если брать книги по IT. Не считал, но оценочно так штук 10-15 книг только про C++. Даже чуточку больше, чем на Java.

И кстати, на hh.ru почему-то много вакансий на C++.

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

Прошу разъяснений.

А что с C++ так все плохо?

Это смотря с чем сравнивать. Если с Java-миром (включая сюда и Scala, и Ceylon, и Kotlin) или каким-нибудь Go, то да. Не хорошо :)

ИМХО, C++ всегда был нишевым языком, который должен был бы применяться лишь в определенных областях, где нужен мощный язык + высокая производительность + хороший контроль за всем. Но в 1980-е и 1990-е годы произошло то, что C++ стал использоваться слишком широко. Что было, наверное, объективно. Но последствия печальные. Слишком много набито шишек. Слишком длительная пауза была между C++98 и C++11.

Сейчас, с одной стороны, ситуация нормализуется и C++ возвращается туда, где он и должен был бы быть. Я здесь упоминал уже продукты вроде ClickHouse и MongoDB — это вот как раз яркие примеры одной ниши, в которой C++ должен присутствовать.

Но, с другой стороны, есть и серьезные отрицательные факторы.

Как я говорил, есть плохая репутация. Неоднократно доводилось слышать о том, как люди уровня CTO или около того (т.е. ответственные за выбор технологического стека) говорили «C++ мы использовать не будем, это боль и сплошные coredump-ы по утрам». При этом у самих этих руководителей нормального опыта работы с C++ и не было.

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

Нам-то это не так страшно, мы давно удобными велосипедами обложились, но в принципе ситуация нехорошая. И распространять свои библиотеки не так просто, как в мире Java, Ruby или Rust-а.

С велосипедами еще одна мрачная грань связана: сам C++ очень сегментирован. Под какие-то специфические ниши без своих велосипедов не обойтись. Где-то люди сразу же перешли на C++17 и активно используют реализации TS-ов из грядущих стандартов. Где-то застряли на уровне C++0x, а то и вообще еще пользуются C++98.

Ну и NIH-синдром в мире C++ — это что-то невероятное ;)

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

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

Спасибо за ответ!

Если интересно, то я обо всем этом рассказывал год назад на одной из конференций: https://events.epam.com/events/gecon-2017/talks/4820 (может потребовать логина через какую-нибудь из соцсетей).

посмотрю чуть позже

посмотрю чуть позже

Хотя я там не столько критиковал C++, сколько старался более-менее объективно рассказать о нем людям, не сведущим в C++.

Ну и это было год назад, я тогда был более оптимистичен :)

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

Скорее второе, зависит от типичных задач, гоферам и параметрический полиморфизм не нужен в их web мирке (где живут одни строки). Кодогенерация решает ту же задачу, что и полиморфизм, HKT, модули/классы, а именно — code reuse в конкретных случаях, когда бойлерплейт генерируется на основе значения. Пример: строки форматирования (regexp, sql, разные форматтеры), протоколы, описанные формально (adtgen, graphql), парсеры из bnf (до свидания костыли, вроде menhir и lex) и.т.д.

Во-вторых, ту же кодогенерацию можно делать внешними средствами

А вот это как раз зло и небезопасно, ибо внешнее средство код воспринимает в лучшем случае как ast (и тогда оно не знает про типы), в худжем транслирует текст в текст, и вот тогда это небезопасный кривой ад.

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

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

А вот это как раз зло и небезопасно, ибо внешнее средство код воспринимает в лучшем случае как ast (и тогда оно не знает про типы), в худжем транслирует текст в текст, и вот тогда это небезопасный кривой ад.

У нас здесь непонимание. Я говорю про случаи, когда вы делаете совсем внешний DSL. Который парсится и обрабатывается отдельным инструментом, а на выходе получается код в целевом языке. Ну вот какой-нибудь bison/flex отличный пример оного.

ruby: http://www.recursion.org/query-parser/

Просмотрел по диагонали. Если под «ast трансформеры в руби» вы подразумевали код вроде вот такого:

class QueryParser < Parslet::Parser
  rule(:term) { match('[^\s]').repeat(1).as(:term) }
  rule(:space) { match('\s').repeat(1) }
  rule(:query) { (term >> space.maybe).repeat.as(:query) }
  root(:query)
end

Работа на уровне AST host-языка была, емнип, в уже обсуждавшемся здесь Nemerle.

Тут нет работы на уровне AST Ruby

Не совсем, здесь парсер парсит строку, а потом на основе ее генерируется объект. Просто в руби с ее поздним связываением, встроенным интерпретатором и правкой классов налету сложно увидеть границу между программированием и метапрограммироваием. Вот еще примеры

https://blog.codeship.com/metaprogramming-in-ruby/

https://thesocietea.org/2015/09/metaprogramming-in-ruby-part-2/

а на выходе получается код в целевом языке. Ну вот какой-нибудь bison/flex отличный пример оного.

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

Там есть статья «Macros that work together», которая описывает макросы в Racket. Dixi.

Есть, но что с того? Сама статья появилась уже после макросистемы Rust, так что... впрочем, см. выше о легионах макропроцессоров.

Что ж, нужно обратиться к самим растовцам с этим вопросом.

Нужно, да:

This system is based on "Macro-by-Example" (PDF link).

посильнее Фауста Гётте

Не знаю, кто такой Фауст Гётте, а вот фамилия Иоганна — Goete. Не надо придумывать никаких удвоенных «т»

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

Что такое метапрограммирование в Ruby я как бы и так знаю, пользовался неоднократно. Как по мне, ничего общего с метапрограммированием в том же Nemerle.

когда теория ЯП была в зачаточном состоянии.

Либо когда в DSL нужно засунуть больше, чем можно выразить в host-языке.

Конкретно этот пейпер не повлиял — повлияли сами макросы Racket. Когда нужно было сделать ссылку, растовцы просто нашли подходящий пейпер, описывающий эти самые макросы, и вставили на него ссылку. Почему выбрали именно этот, а не более ранний — а фиг его знает. Может до этого не было нормальных пейперов по макросам в Racket. Сами макросы давно были, а пейпер вышел позже. Или чем-то другим руководствовались. Но никакого time paradox тут нет.

Знаю я одну программу физического моделирования, референсный пейпер по которой вышел аж через 3-4 года после её фактического распространения среди физиков. Ну вот так получилось. Это не отменяет того факта, что эти 3-4 года физики пользовались программой и получали какие-то важные результаты. А теперь все, конечно, уже ссылаются на новую статью.

см. выше о легионах макропроцессоров.

Тем не менее, растовцы сослались на макросы Racket, а не легион.

Конкретно этот пейпер не повлиял — повлияли сами макросы Racket

Выше же приведена ссылка на статью (1986 года), которая реально повлияла, зачем ты продолжаешь упорствовать?

Знаю я одну программу физического моделирования, референсный пейпер по которой вышел аж через 3-4 года после её фактического распространения среди физиков.

Ты такой знающий.