Здравствуйте, BulatZiganshin, Вы писали:

BZ>тут проблема скорее в противоположном — чтоб мои слова не воспринимались слишком близко к сердцу
Я как раз близко к сердцу и не воспринимал, но раз дискуссия продолжается теми аргументами, которые есть, значит кто то все таки это воспринимает именно так

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

Теперь не применительно только к этой фразе а вывод в общем. Каждый инструмент создается as main concept для определенных задач. Кто то ниже говорил "разделять сервер и морду". Я совершенно с этим согласен и как видишь даже в бессмысленный спор не вступаю. Вопрос лишь в том кто будет морду реализовать.
Я прекрасно представляю ассемблер с шаблонами и примитивами синхронизации, но и вы представте C# в виде монстра, который решает не только задачи прикладного програмирования, а еще и будет перекручен конструкциями с определенными unmanaged оговорками для свободного манипулирования ресурсами под уровень ядра, либо все таки МС придется извратится чтобы все возможные варианты изобразить MSIL компилером. Все равно это будут не логичные для его контекста описания. Вообщем заметьте Г. получается как с одной, так и с другой стороны. Не нужно все это.
Пускай C++ занимается задачами в своем стиле и не нужно ему всего что касается managed расширений. Человек, который не хочет следить за ресурсами сам, либо не умеет оперировать типами, пускай не лезет в ++ (это не характеризует недостатки языка). При правильном архитектурном подходе, я поверь мне уже практически избавился от страшных снов связанных с этим, абсолютно. Каждый инструмент требует определенных навыков, опыта и мозгов. Кесарю, кесарево. Железная истина. Для прикладников языки другие.

BZ>в 80-х ...

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

BZ>последние 15 лет С++ развивается только в направлении усиления шаблонов.

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

BZ>однако когда речь доходит ло прикладного программирования и эффективность оказывается не главным, тут С++ напоминает Винни-Пуха, который прикидывался тучкой в языке нет GC и type-safe generic references, синхронизации, клозур и т.п. ну и фиг с ним! мы всё это сэмулируем! в результате чего есть язык С++, содержащий массу конструкций, которые прикладному программисту просто не следует использовать, и многочисленные бибилиотеки, которые худо-бедно эмулируют возможности, напрямую встроенные в другие, более современные языки

Вот и пускай будут они туда встроены. !!!! О БОЖЕ, мы наконец приходим к тому, к чему с самого начала стремились.
1. Я счастлив, что простому прикладнику наконец сделали инструменты, которые позволяют меньше думать и больше работать, но это отнюдь не означает что С++ плох. Ему просто все эти расширения не нужны.
2. Если человек владеет С++ — это должно четко обозначать что он в состоянии за время не меньшее, чем прикладник с помощью своего инструмента, может эмулировать все те вещи о которых мы говорим.
Для меня это кристальная истина. Все остальные лишь используют язык, в каких то узких целях, который им возможно и не нужен.


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


То что язык развивается в сторону метапрограммирования на базе шаблонов — это совершенно логичесное и естественное развитие языка данного уровня.

BZ>вот поэтому вы и need a complex language — чтобы созранить совместимость с кодом 30-летней давности, сгенерить как можно более эффективную программу, а затем попытаться как-то сэмулировать современные языки.

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

BZ>я тут выше приводил пару примеров кода в хаскел, напиши их аналоги в С++ и сравни сам. если вместо изучения всех этих legacy features и методов эмуляции modern features изучать напрямую современный язык, то ты здорово сэконишь во времени изучения и затем во времени написания/отладки кода.

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

BZ>именно об этом я и говрю — что в С++ thread-safe программирование требует специального изучения и в job offers, например, указывается как отдельное требование чтобы понять, насколько это смешно, представьте себе скажем требование "умение вызывать функции рекурсивно". это тоже может специальным умением в языке типа Фортрана, где это не поддерживалось

Сравнивать "рекурсивный вызов" и "thread-safe" — это все равно что в правах на вождение автомобиля указывать уровень владения самокатом. Давайте не опускаться до такого уровня. Человек ничего не знающий о потоках и разделяемых ресурсах и в C# репу перегреет такими понятиями как ThreadMutex и т.д.

BZ>т.е. опять речь о complex language, порождённом тем, что современные концепции программирования в нём — нечто дополнительно прикрученное сбоку с теми самыми километрами художеств

Где явное определение того, что так называемый complex language охватывает весь спектр современных концепций и что есть весь спектр современных концепций?
Я надеюсь понятно без лишних объяснений почему вам не удастся быть объекивных в этой части вопроса.