Здравствуйте, 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++ практически все это под вашим контролем.

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