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

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

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

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

S>>Вы сказали конкретно вот это:
S>>[q]Цель была прежде всего в том, чтобы раздвинуть возможности C в сторону ЯВУ, не теряя при этом его низкоуровневых качеств.[/q]
S>>Т.е. если возможности Си нужно было раздвигать в сторону ЯВУ, значит ЯВУ он не являлся. Если следовать написанному вами.

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

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

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

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>>Я бы еще понял претензии по поводу эффективности и экономичности (хотя я уже как-то давал в профильных форумах [url=https://eao197.blogspot.com/2024/09/progc.html]ссылку[/url] на использование возможностей современного C++ как раз для экономичности).

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

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

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

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

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

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

ЕМ>А много ли даст реализация тех модулей в соответствии со стандартом, по сравнению с тем, что можно сделать уже имеющимися средствами языка? То есть - даст ли она [i]качественное[/i] улучшение, или же только количественное?

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

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

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

ЕМ>Это возможно в [i]любом[/i] языке.

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

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

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

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

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

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

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

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

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

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

Теги:

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

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