Новое сообщение в форум Компьютерные священные войны

Форум	Компьютерные священные войны
Тема	Как правильно задавать вопросы

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

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

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

S>Нет.

ЕМ>>ALGOL-68 и Modula.

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

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

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

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

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

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

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

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

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

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

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

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

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

ЕМ>>[url=https://en.wikipedia.org/wiki/Timeline_of_programming_languages]Да пожалуйста[/url].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail