Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>>В этом нет вообще ничего, связанного с совместимостью с C.
S>>А вот что говорит сам Страуструп (Evolving a language in and for the real world: C++ 1991-2006, стр.46):

ЕМ>Так кто ж его заставлял использовать "auto" в исходном виде? Если уж отчаянно не хотелось вводить что-нибудь вроде "deduced" или "autotype", ничто не мешало сперва ввести "_auto", с последующей постепенной подгонкой "auto" к тому же смыслу.

Это вы у Страуструпа спросите.

Канва же диалога была такой: я привел пример с auto который показывал, насколько важна была совместимость с Си в то время, потом заявляется авторитетный (нет) авторитет (нет) Музыченко и заявляет, что "в этот нет вообще ничего, связанного с совместимостью с Си". На что авторитетному (нет) авторитету (нет) Музыченко предъявляется цитата из первоисточника.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Он был очень примитивен по сравнению с "серьезными" ЯВУ того времени.

Это с какими, например? COBOL и PL/I?
Ada появилась только в 1983-ем.
Modula-2 -- приблизительно в то время, когда Страуструп начинал работы над C with Classes, по своим возможностям была не так уж далеко от Си.

S>>сам Страуструп говорил: "С++ проектировался с целью обеспечить средства организации программ, присущие языку Simula

ЕМ>Да, но не потому, что у языка Simila было такое название, а потому, что он для тех времен был достаточно продвинутым.

Э... Вы с чем спорите? Я изначально написал: "Цель создания C++ была в том, чтобы скрестить Симулу с Си. Что выразилось в добавлении в Си классов и наследования." Что соответствует словам Страуструпа. При чем здесь "у языка Simula было такое название"?

S>>Ada и Clu (и ML, емнип) упомининались Страуструпом как первоисточники.

ЕМ>Возможных для заимствования первоисточников были десятки.

Список в студию, пожалуйста.

ЕМ>Ну, если сравнивать только подходы, похожие на C++, то конечно.

Покажите другие подходы.

S>>Огласите свой список языков без сборщика мусора, в которых шаблоны гибче, чем в C++?

ЕМ>Какая вообще связь у шаблонов со сборкой мусора, кроме весьма отдаленной?

Связь не у шаблонов, а у возможностей и ограничений языков с GC и без.
C++ находится в категории языков без GC, поэтому сравнивать его с условными Haskell/OCaml/Scala ну такое себе.
Отсюда и формулировка просьбы.

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

S>>А то, что шаблоны не просты, так это как раз следствие их гибкости.

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

Бла-бла-бла.
Шаблоны позвляют делать очень многое. Поэтому они очень гибкие. Обратной стороной является их сложность.

Но если вы 40 лет программируете на Си с классами, а в шаблоны не умеете, что и оценки ваши от пустого бла-бла-бла ничем не отличаются.

ЕМ>Я уже много раз рассказывал.

Ни одного случая не помню

ЕМ>Главное — не пытаться запихать всю потребную функциональность в искусственно ограниченные синтаксис и семантику.

Опять пустопорожнее бла-бла-бла.

S>>Вы хоть знаете как в C++ сделать адаптацию своего типа к structured binding?

ЕМ>Представляю в общих чертах, ибо пока не требовалось настолько, чтоб в этом разбираться досконально.

Т.е. Пастернака не читал, но осуждаю.
Даже до того, что есть со structured binding пришлось идти очень долго. А в области ООП C++ тогда был один из первопроходцев среди мейнстримных языков. Тогда как в 1980-х и даже в 1990-х этого опыта просто не было. Как и языков с pattern matching-ом в мейнстриме.

ЕМ>Кстати, подобные вещи легко делались бы на "функционально адекватных" макросах, имейся таковые в языке. И не было бы нужды впихивать это в сам язык, и каждый мог бы хоть использовать готовые конструкции из библиотек, хоть делать сам на собственный вкус и потребность. А так и язык в очередной раз усложнили/утяжелили, и способы управления связыванием зафиксировали, без возможности их изменения/дополнения.

Пример кода можете показать? А то опять все очень похоже на привычные для вас пустопорожние бла-бла-бла.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>У него и так был (и до сих пор есть) нехилый шанс. Но, если б его развивали в сторону реального удобства (но без ущерба для эффективности), то с него меньше бежали бы, разочарованные экспоненциальным ростом путаницы при линейном росте объема/сложности проекта.

Его и развивают в сторону реального удобства. Сейчас очень многое стало проще и лучше.

ЕМ>Почему нельзя гнать на него за то, что всю историю отчаянно сопротивлялся добавлению новых ключевых слов, упорно навешивая новые семантики на существующие, вплоть до абсурда?

Какую "всю историю"? Уже 27 лет как комитет занимается развитием.

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

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

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

S>заявляется авторитетный (нет) авторитет (нет) Музыченко и заявляет, что "в этот нет вообще ничего, связанного с совместимостью с Си".

Именно так. Ибо неавторитетный неавторитет Музыченко в упор не понимает, какие могут быть "проблемы с совместимостью с C", когда испокон веку известны такие элементарные способы управления компиляцией, как ключи командной строки, прагмы, псевдокомментарии и прочее. А Страуструп не затруднил себя более подробным объяснением суть "проблемы совместимости", поэтому неавторитетный неавторитет склонен полагать, что Страуструп банально зациклился на несуществующей проблеме (это со всеми бывает).

Может быть, Вы сумеете лучше Страуструпа объяснить, в чем могла бы выражаться "возможная несовместимость с C"?

Здравствуйте, Евгений Музыченко, Вы писали:

S>>заявляется авторитетный (нет) авторитет (нет) Музыченко и заявляет, что "в этот нет вообще ничего, связанного с совместимостью с Си".

ЕМ>Именно так.

Ровно в этом же русле можно заявить, что Музыченко не умеет программировать, C++а не знает, а свои комментарии на RSDN пишет исключительно в нетрезвом виде.

ЕМ>А Страуструп не затруднил себя более подробным объяснением суть "проблемы совместимости"

Вы хоть документ по ссылке смотрели?

After a proposal by Dag Bruck, both C99 and C++98 banned this “implicit int”. Since there is now no legal code for “auto q” to be incompatible with, we allowed it. That incompatibility was always more theoretical than real (reviews of huge amounts of code confirm that), but using the (unused) keyword auto saved us from introducting a new keyword. The obvious choice (from many languages, including BCPL) is let, but every short meaningful word has already been used in many programs and long and cryptic keywords are widely disliked.

Ну и стоит обратить внимание на то, что постоянно упоминается "мы".

ЕМ>Может быть, Вы сумеете лучше Страуструпа объяснить, в чем могла бы выражаться "возможная несовместимость с C"?

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

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

ЕМ>>Он был очень примитивен по сравнению с "серьезными" ЯВУ того времени.

S>Это с какими, например? COBOL и PL/I?

Вы издеваетесь? Эти появились еще до того, как C более-менее оформился и пошел в массы. Также до C были LISP, SNOBOL, ALGOL-68, Simula-67, REFAL, SETL — это только из наиболее популярных. Между C и C++ были (опять-таки из наиболее известных) Prolog, Simula-74, Smalltalk, Modula.

S>Вы с чем спорите?

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

S>"Цель создания C++ была в том, чтобы скрестить Симулу с Си. Что выразилось в добавлении в Си классов и наследования."

у Вас выглядит, как банальное "возьмем общий подход и синтаксис от одного языка, добавим конструкции из другого, и получим новый язык". Если бы Страуструп их "просто скрестил", у него получился бы просто еще один язык, который вряд ли снискал бы такую популярность. Несомненная заслуга Страуструпа в том, что он не "просто скрестил", а постарался сделать это максимально аккуратно и экономно, чтобы добавленные возможности не потащили за собой чрезмерное утяжеление кода. С реализацией исключений он, правда, просчитался, сразу сделав ее чрезмерно размашистой. А в ряде других моментов продолжал откровенно крохоборствовать. Это и удивляет.

S>При чем здесь "у языка Simula было такое название"?

При том, что Simula сама по себе прекрасно справлялась [почти] с любыми высокоуровневыми задачами, для которых предназначался C++. Не будь цели сделать универсальный язык, можно было бы продолжать обходиться C для простых/низкоуровневых задач, и "серьезными" ЯВУ, включая Simula, для остальных.

ЕМ>>Возможных для заимствования первоисточников были десятки.

S>Список в студию, пожалуйста.

Да пожалуйста.

S>Покажите другие подходы.

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

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

S>Связь не у шаблонов, а у возможностей и ограничений языков с GC и без.
S>C++ находится в категории языков без GC, поэтому сравнивать его с условными Haskell/OCaml/Scala ну такое себе.

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

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

S>родите, например, список языков, в которых шаблоны гибче, чем в C++?

Я никогда не интересовался C++-подобными (то есть, "функциональными") реализациями шаблонов в процедурных языках, ибо все они очень ограничены в силу самой концепции. Более-менее адекватная реализация возможна только в функциональных языках, а ими я тоже не особо интересуюсь. Чтобы в процедурном языке получить адекватные возможности метапрограммирования, нужна процедурная же концепция хоть шаблонов, хоть макросов. Ну, или реализация полноценного функционального языка внутри процедурного, что вряд ли имеет смысл.

S>Шаблоны позвляют делать очень многое.

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

S>Поэтому они очень гибкие. Обратной стороной является их сложность.

Если перед "гибкие" добавить "относительно", а перед "сложность" — "многократно преувеличенная", то соглашусь.

S>Но если вы 40 лет программируете на Си с классами, а в шаблоны не умеете

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

S>Т.е. Пастернака не читал, но осуждаю.

Почему не читал? Как раз читал. Видел, что в ряде случаев это может быть полезно, но у меня пока не было насущной потребности это применять. И, кстати, адекватный макропроцессор, будь он в языке вместо шаблонов, позволил бы относительно просто реализовать такое в виде надстройки — то есть, будучи сделано кем-то для себя, оно автоматически стало бы доступно всем пользователям языка. А так оно появляется в реализациях только по мере поддержки очередных стандартов разработчиками компиляторов.

S>Даже до того, что есть со structured binding пришлось идти очень долго.

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

S>в области ООП C++ тогда был один из первопроходцев среди мейнстримных языков.

К этой части претензий как раз [почти] нет.

S>Пример кода можете показать?

А смысл? Если Вам понятна сама идея, то что может дать код сверх нее? Если же идея со слов непонятна, то как Вы собираетесь понимать код?

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

N>Его и развивают в сторону реального удобства. Сейчас очень многое стало проще и лучше.

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

Если б этот изначальный "ужас-ужас" был неизбежен (как, например, многие корявые ранние решения, продиктованные тогдашними жесткими ограничениями на ресурсы), я б не воспринимал это столь болезненно. Но очевидно же, что никаких объективных предпосылок не было. Просто было сказано "да будет так". Это ж регулярно случается во всех областях.

N>Уже 27 лет как комитет занимается развитием.

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

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

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

S>Вы хоть документ по ссылке смотрели?

Я подобные "объяснения" от него встречал в разных его работах, и не могу оценивать их, как профессиональные. Максимум — как капризы, как упертость, не более.

S>

After a proposal by Dag Bruck, both C99 and C++98 banned this “implicit int”...

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

S>Ну и стоит обратить внимание на то, что постоянно упоминается "мы".

Да, это называется "коллективное заблуждение", и даже "коллективное помешательство".

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Чтоб реально убить C++, язык для начала должен быть полностью с ним совместим, как C++ сперва был полностью совместим с C, и сохранять эту совместимость какое-то время. Дураку понятно . . .

. . . что этим языком может быть только C++

Здравствуйте, Евгений Музыченко, Вы писали:

S>>Вы хоть документ по ссылке смотрели?

ЕМ>Я подобные "объяснения" от него встречал в разных его работах, и не могу оценивать их, как профессиональные. Максимум — как капризы, как упертость, не более.

- У Вас была какая-то тактика с самого начала и вы её придерживались?
— С самого начала у меня была какая-то тактика и я её придерживался.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Вы издеваетесь?

Нет.

ЕМ>ALGOL-68 и Modula.

И чем же они ЯВУ, а Си -- нет?

Включение же в список кучи языков с GC для сравнения их с чистым Си -- это от большого ума?
Как и попытка сопоставить Си и Prolog (популярность которого, даже в конце 1980-х и начале 1990-х сильно преувеличена).

S>>Вы с чем спорите?

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

Значит вы ничего не знаете.

S>>"Цель создания C++ была в том, чтобы скрестить Симулу с Си. Что выразилось в добавлении в Си классов и наследования."

ЕМ>у Вас выглядит, как банальное "возьмем общий подход и синтаксис от одного языка, добавим конструкции из другого, и получим новый язык".

Так по факту же именно это и получилось.

S>>При чем здесь "у языка Simula было такое название"?

ЕМ>При том, что Simula сама по себе прекрасно справлялась

Да, да, да. Страуструпа, вы, видимо, не читали от слова совсем:

Однако реализация самого языка Simula не масштабировалась в той же степени, что и моя программа. В результате весь проект чуть не закончился крахом. В то время я пришел к выводу, что реализация Simula (в отличие от самого языка) была ориентирована на небольшие по объему программы, а для больших не приспособлена. На связывание отдельно скомпилированных классов уходила масса времени: на компиляцию 1/30 части программы и связывание ее с остальными, уже откомпилированными модулями тратилось больше времени, чем на компииляцию и связывание всей программы как монолита. Думаю, что, вероятнее всего, это была проблема используемого компоновщика, а не самого языка Simula, но это слабое утешение. Кроме того, производительность программы была такой низкой, что не оставляла надежд получить от симулятора хоть сколько-нибудь полезные данные. Плохие показатели производительности были обусловлены языком и его реализацией, а не приложением. Проблема накладных расходов является в Simula фундаментальной и неустранимой. Она коренится в некоторых особенностях языка и их взаимодействиях: проверке типов во время исполнения, гарантированной инициализации переменных, поддержке параллельности, сборке мусора для объектов, созданных пользователем, и записей активации процедур.

Так что ваше мнение о "прекрасно справлялась" и мнение Страуструпа здесь драматически расходятся.

ЕМ>>>Возможных для заимствования первоисточников были десятки.

S>>Список в студию, пожалуйста.

ЕМ>Да пожалуйста.

Это называется "на деревню дедушке".

S>>Покажите другие подходы.

ЕМ>Я уже неоднократно показывал — почти любой мало-мальски продвинутый макрогенератор. Где макрос — это не просто кусок текста, в который можно подставить параметры, а процедура/функция (обычно на особом макроязыке), выполняемая на этапе компиляции. Которая может разобрать список своих параметров, сопоставить их с известными компилятору объектами (типами, переменными, функциями и т.п.)

А мы сейчас точно о макросах говорим? Макросы же обрабатываются до начала работы компилятора и формируют код, который уже идет на вход компилятору. Т.е. для макроса еще нет "известных компилятору объектов".

Кроме того, именно то, что вы описываете, как раз C++ными шаблонами и делается: разбор параметров, сопоставление и т.д.

И позвольте спросить, а как в этом вашем идеальном макрогенераторе решать ту проблему, для которой в C++ добавили специализацию шаблонов (хоть полную, хоть частичную)?

ЕМ>породить текст для последующей компиляции, подставив туда хоть параметры (как в исходном, так и в преобразованном виде), хоть произвольно сгенерированные строки

А это уже завозят в рамках C++26. Не без помощи шаблонов.

ЕМ>при необходимости сопровождая свою работу сообщениями в общий поток вывода компилятора.

Этого пока нет.

ЕМ>Да, это гораздо сложнее тупых сишных макросов, и даже немного сложнее первой инкарнации плюсовых шаблонов

Мне кажется, что вы и про первую инкарнацию шаблонов знаете почти ничего.

S>>Связь не у шаблонов, а у возможностей и ограничений языков с GC и без.
S>>C++ находится в категории языков без GC, поэтому сравнивать его с условными Haskell/OCaml/Scala ну такое себе.

ЕМ>Вот вообще не вижу ни малейшей связи.

Очередной пустопорожний бла-бла-бла поскипан.

S>>родите, например, список языков, в которых шаблоны гибче, чем в C++?

ЕМ>Я никогда не интересовался C++-подобными (то есть, "функциональными") реализациями шаблонов в процедурных языках, ибо все они очень ограничены в силу самой концепции. Более-менее адекватная реализация возможна только в функциональных языках, а ими я тоже не особо интересуюсь. Чтобы в процедурном языке получить адекватные возможности метапрограммирования, нужна процедурная же концепция хоть шаблонов, хоть макросов. Ну, или реализация полноценного функционального языка внутри процедурного, что вряд ли имеет смысл.

Т.е. заявления есть, подтверждений нет. Ожидаемо.

ЕМ>А смысл? Если Вам понятна сама идея, то что может дать код сверх нее? Если же идея со слов непонятна, то как Вы собираетесь понимать код?

А вы рискните. Пока что вы в очередной раз выступили в духе "за все хорошее против всего плохого". И с конкретикой у вас, по традиции, очень плохо. Очень.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, so5team, Вы писали:

S>>Вы хоть документ по ссылке смотрели?

ЕМ>Я подобные "объяснения" от него встречал в разных его работах, и не могу оценивать их, как профессиональные. Максимум — как капризы, как упертость, не более.

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

Другое дело Музыченко. Вот это голова!

Здравствуйте, Евгений Музыченко, Вы писали:

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

Раз уж зашла такая пьянка, то что за низкоуровневые и архитектурно-зависимые возможности вы подразумеваете?
Складывается ощущение, что их не так уж и много:

— указатели;
— union;
— целочисленные типы незафиксированного размера (short/int/long может быть разного размера);
— отсутствие строкового типа;
— какие-то UB (вроде целочисленного переполнения).

Что еще?

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

ЕМ>>ALGOL-68 и Modula.

S>И чем же они ЯВУ, а Си -- нет?

Я не говорил, что C — "не ЯВУ". Я имел в виду, что он Я менее высокого У, чем любой из языков, которые принято относить к ЯВУ.

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

Подход, принятый в C (и частично сохраненный в C++), позволяет малой кровью реализовать простое ядро языка на любой новой платформе, после чего туда автоматически переносится вся стандартная библиотека, написанная на нем самом.

S>Включение же в список кучи языков с GC для сравнения их с чистым Си -- это от большого ума?

Я не понимаю, отчего Вы так уцепились за GC, который тут вообще не при делах. "Кто такой Студебеккер? Это ваш родственник Студебеккер? Папа ваш Студебеккер? Чего вы прилипли к человеку?".

S>Как и попытка сопоставить Си и Prolog (популярность которого, даже в конце 1980-х и начале 1990-х сильно преувеличена).

Я ж не сопоставляю напрямую. Я лишь показываю, что задачи, которые традиционно решались с помощью ЯВУ, еще с 60-х были вполне покрыты имевшимися тогда языками, и вряд ли кому-то приходило в голову использовать C вместо любого из этих языков для мало-мальски серьезного проекта. Основной причиной появления C было стремление избавиться от написания низкоуровневого кода на ассемблере, а отнюдь не заменить какой-нибудь PL/1 или Fortran-IV. И у C++ поначалу тоже не было шансов полноценно заменить популярные в то время ЯВУ, для этого потребовалось лет десять устаканивания и развития.

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

S>Значит вы ничего не знаете.

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

S>

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

Вас не насторожило ни слово "реализация", ни это?

S>

вероятнее всего, это была проблема используемого компоновщика, а не самого языка Simula

А если все дело было прежде всего в том, что

S>

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

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

S>Макросы же обрабатываются до начала работы компилятора

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

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

S>именно то, что вы описываете, как раз C++ными шаблонами и делается: разбор параметров, сопоставление и т.д.

И сколько лет прошло от появления в C++ шаблонов, которые внезапно оказались Тьюринг-полными, до появления первых робких средств делать этот разбор иначе, как посредством побочных эффектов? Как у Вас реально поворачивается язык называть все эти костыли иначе, чем уродством?

S>как в этом вашем идеальном макрогенераторе решать ту проблему, для которой в C++ добавили специализацию шаблонов (хоть полную, хоть частичную)?

Элементарно. "Макрос" при обработке своего "вызова" анализирует список параметров (напомню, в этой концепции ему доступны все известные на данный момент компилятору типы и значения) и либо порождает соответствующий код, либо выдает сообщение об ошибке. Для вящего удобства и красоты можно добавить третий вариант — "макрос" завершается с результатом "это определение не подходит" (что будет аналогично SFINAE), и компилятор ищет другой макрос с тем же именем и подходящим набором параметров. Чисто технически это не обязательно, можно обойтись первыми двумя путями, а нужные варианты кода порождать вызовом других "макросов", как это принято делать с функциями.

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

S>А это уже завозят в рамках C++26. Не без помощи шаблонов.

ЕМ>>при необходимости сопровождая свою работу сообщениями в общий поток вывода компилятора.
S>Этого пока нет.

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

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

S>Да какой Страуструп профессионал?

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>>ALGOL-68 и Modula.

S>>И чем же они ЯВУ, а Си -- нет?

ЕМ>Я не говорил, что C — "не ЯВУ". Я имел в виду, что он Я менее высокого У, чем любой из языков, которые принято относить к ЯВУ.

Вы сказали конкретно вот это:

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

Т.е. если возможности Си нужно было раздвигать в сторону ЯВУ, значит ЯВУ он не являлся. Если следовать написанному вами.

ЕМ>Принципиальная разница в том, что

Простите очередное бла-бла-бла поскипал, т.к. там нет никакой конкретики.

ЕМ>Подход, принятый в C (и частично сохраненный в C++), позволяет малой кровью реализовать простое ядро языка на любой новой платформе, после чего туда автоматически переносится вся стандартная библиотека, написанная на нем самом.

Э... А что этому препятствует в Pascal, Modula-2 и Ada?
Либо вы в очередной раз не смогли внятно сформулировать какую-то мысль, либо я не понимаю, чем Си или C++ в этом вопросе лучше условного Modula-2.

S>>Включение же в список кучи языков с GC для сравнения их с чистым Си -- это от большого ума?

ЕМ>Я не понимаю, отчего Вы так уцепились за GC,

Оно заметно.

EM>который тут вообще не при делах.

Очень даже.
Вот в C++ мы можем иметь дело с шаблоном:

template<class T>
class value_holder {
  T _value;
public:
  ...
};

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

Тогда как в языках с GC этих вопросов нет.

S>>Значит вы ничего не знаете.

ЕМ>Я сужу по тому, что Вы пишете о C++. Вы всегда выступали прежде всего за совместимость, универсальность, обобщенность, богатство функционала и т.п., а чтоб за эффективность, экономичность, прозрачность, ортогональность функционала — почти не помню.

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

S>>

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

ЕМ>Вас не насторожило ни слово "реализация", ни это?

Нет. Мы же в реальном мире живем. Если есть некая абстрактная Simula, но нет вменяемой реализации для нее, то сыт не будешь.
Это как сейчас с C++ными модулями. В теории они есть. На практике для очень многих их нет. Хотя в стандарте описаны, да.

ЕМ>то не проще ли было допилить и сам язык, и его реализацию, чтобы устранить самые критичные проблемы?

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

S>>Макросы же обрабатываются до начала работы компилятора

ЕМ>Так обрабатываются только самые примитивные, тупые макросы. Их реализация в C — отличный пример мертворожденной концепции.

А где макросы не примитивные и не тупые? Рискну предположить, что в Lisp-е или каком-нибудь Nemerle.

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

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

S>>именно то, что вы описываете, как раз C++ными шаблонами и делается: разбор параметров, сопоставление и т.д.

ЕМ>И сколько лет прошло от появления в C++ шаблонов, которые внезапно оказались Тьюринг-полными, до появления первых робких средств делать этот разбор иначе, как посредством побочных эффектов?

Каких таких эффектов, выражайтесь яснее, плз.

ЕМ>Как у Вас реально поворачивается язык называть все эти костыли иначе, чем уродством?

Я вообще не даю оценок, а прошу показать где обобщенное программирование реализовано лучше и гибче.

S>>как в этом вашем идеальном макрогенераторе решать ту проблему, для которой в C++ добавили специализацию шаблонов (хоть полную, хоть частичную)?

ЕМ>Элементарно. "Макрос" при обработке своего "вызова" анализирует список параметров (напомню, в этой концепции ему доступны все известные на данный момент компилятору типы и значения) и либо порождает соответствующий код, либо выдает сообщение об ошибке. Для вящего удобства и красоты можно добавить третий вариант — "макрос" завершается с результатом "это определение не подходит" (что будет аналогично SFINAE), и компилятор ищет другой макрос с тем же именем и подходящим набором параметров. Чисто технически это не обязательно, можно обойтись первыми двумя путями, а нужные варианты кода порождать вызовом других "макросов", как это принято делать с функциями.

Где такое чудо можно увидеть?

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

В современном C++ практически все это под вашим контролем. За исключением унаследованного из Си неявного преобразования целочисленных типов.

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

S>что за низкоуровневые и архитектурно-зависимые возможности вы подразумеваете?

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

Кстати, имейся в языке упомянутые "умные макросы", с их помощью было бы просто и изящно делать множество удобных и одновременно эффективных вещей. Например, строить таблицы данных или указателей на функции, автоматически добавляя туда информацию о типах, но не так, как это делает RTTI, а компактно и удобно для обработки. Или непосредственно указывая в тексте программы строки на разных языках, чтобы не выносить их в отдельные файлы и не давать тем строкам явные имена/коды. Делать обработку синтаксисов наподобие XML/HTML/JSON во время компиляции. И многое другое.

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

σ>Инкапсуляцию придумали когда делали симуляцию поведения распределённых систем. В этом случае инкапсуляция — адекватная модель для предметной области. Но оопе-сектанты пропагандируют что для всех областей.

Инкапсуляция появляется сама собой, её не надо изобретать.
Например, в функциональном программировании в замыкании переменные не видны для вызыващего кода. Если вы создаёте поток, то переменные внутри потока точно так же не видны снаружи, и это тоже инкапсуляция.
Закрытые переменные модуля точно такая же инкапсуляция — эта штука была была еще до ООП.

Товарищи просто дали название такому явлению.

Здравствуйте, Евгений Музыченко, Вы писали:

S>>что за низкоуровневые и архитектурно-зависимые возможности вы подразумеваете?

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

Блин, да вы вообще хоть когда-нибудь в конкретику умеете?

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

Возьмите, например, std::for_each. Это же что, наследие архитектурно-зависимых возможностей Си?

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

А если вы про RTTI и поддержку исключений, то покажите как этого же достичь в Си с той же эффективностью.
И если вам (не, не вам, а нормальным людям) в проекте нужны и RTTI, и исключения, то нахера им оглядываться на "низкоуровневые и архитектурно-зависимые возможности"?

PS. Вопросы по привычке позадавал. Хотя есть ощущение, что нет надежды получить вменяемые ответы.

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

S>Вы сказали конкретно вот это:
S>

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

S>Т.е. если возможности Си нужно было раздвигать в сторону ЯВУ, значит ЯВУ он не являлся. Если следовать написанному вами.

Я ж в смежных текстах всегда добавляю эпитет — "серьезных" или "взрослых" ЯВУ. В этой вот фразе не посчитал нужным это отметить.

Но ни в начале 70-х, н в 80-е, большинство специалистов не признавали C "настоящим ЯВУ". Его всегда ставили где-то посреди между продвинутым ассемблером и любым из популярных ЯВУ, которые подчеркнуто избегали использовать понятия "байт", "слово", "адрес" и т.п.

ЕМ>>Подход, принятый в C (и частично сохраненный в C++), позволяет малой кровью реализовать простое ядро языка на любой новой платформе, после чего туда автоматически переносится вся стандартная библиотека, написанная на нем самом.

S>Э... А что этому препятствует в Pascal, Modula-2 и Ada?

Как минимум то, что подход был принят в C, а двух последних на тот момент не существовало. Но и в Pascal отсутствует разделение на ядро и библиотеку, поэтому любая реализация Pascal обязана уметь работать с файлами, даже если на платформе это понятие вовсе отсутствует, а на самом языке эту работу не написать компактно и эффективно, без хакерства и добавления скрытых функций в язык, как на "минимальном" Ada адекватно не написать его функций многозадачности. В Modula-2 Вирт эти проблемы в целом решил, но очевидно же, что как раз под влиянием C.

S>чем Си или C++ в этом вопросе лучше условного Modula-2.

C++ уже мало чем лучше — на ядре какого-нибудь C++03, например, не написать реализации каких-нибудь лямбда-функций, а на C, как известно, легко пишется реализация почти всего функционала классов C++. Это я снова о масштабировании языка его собственными средствами, но без излишеств и чрезмерной сложности.

S>в C++ мы вынуждены считаться с тем, является ли T ссылкой или указателем, насколько сохраняется семантика value_holder для этого случая, нужно ли нам что-то предпринимать с классом value_holder, если T -- это ссылка.
S>Тогда как в языках с GC этих вопросов нет.

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

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

S>Я бы еще понял претензии по поводу эффективности и экономичности (хотя я уже как-то давал в профильных форумах ссылку на использование возможностей современного C++ как раз для экономичности).

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

S>Но прозрачность и ортогональность-то здесь каким боком?

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

S>Если есть некая абстрактная Simula, но нет вменяемой реализации для нее, то сыт не будешь.

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

S>Это как сейчас с C++ными модулями. В теории они есть. На практике для очень многих их нет. Хотя в стандарте описаны, да.

А много ли даст реализация тех модулей в соответствии со стандартом, по сравнению с тем, что можно сделать уже имеющимися средствами языка? То есть — даст ли она качественное улучшение, или же только количественное?

S>А где макросы не примитивные и не тупые?

Например, в ассемблере System/360. В PL/1 вроде как тоже был вполне годный макропроцессор. Во многих ассемблерах макроязык позволял вырезать подстроки, перебирать фактические параметры, ветвиться, делать повторы и т.п. То есть, к тому времени уже долгое время были достойные примеры, только бери из каждого лучшее.

S>Это возможно в динамически типизируемом языке, типа Lisp-а.

Это возможно в любом языке.

S>В статически типизируемом вы для этого должны оперировать понятиями языка (вроде анотаций в Java или шаблонов C++), либо работать на уровне лексем. Но на уровне лексем возникают проблемы с тем, чтобы понять что конкретная лексема будет означать.

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

ЕМ>>И сколько лет прошло от появления в C++ шаблонов, которые внезапно оказались Тьюринг-полными, до появления первых робких средств делать этот разбор иначе, как посредством побочных эффектов?
S>Каких таких эффектов, выражайтесь яснее, плз.

Ну как еще можно было сделать последовательный перебор параметров шаблона до появления с C++11 явных средств для этого, кроме как на побочных эффектах вычисления шаблонных выражений?

S>прошу показать где обобщенное программирование реализовано лучше и гибче.

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

S>Где такое чудо можно увидеть?

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

S>В современном C++ практически все это под вашим контролем.

Угу — только, как правило, под неявным и, как правило, через жопу.