Я, кстати, не привёл вторую часть процитированного абзаца, а, кажется, она всё-таки не менее важна.> The "interface specification" for these "components" usually involves a list of tools in which an engineer has received "training." (I really detest the use of the word "training" in relation to professional activities. Training is what you do to dogs. What you should be doing with people is educating them, not training them. There is a big, big difference.)
В связи с этим становятся, в частности, лучше понятны ключевые рещения Java/C#
> Нужно понимать, что во времена юности С++ вопрос "чем в современных языках расчётов (читай 'Фортран') могут быть полезны ваши Объекты. Тип complex у нас уже есть, и как раз с полной магией" был вполне себе в силе. То есть, Бъярни выбрал расширяемость вместо встроенности.
> А вот Хейльсберг в С# всегда занимал консервативную позицию: "мы улучшаем не фичи, а сценарии". То есть, если у пользователей языка есть конкретная проблема, то команда выбирает такой дизайн, который хорошо решает именно эту задачу, а не универсальный ответ на множество несвязанных задач. Характерный пример — оператор infoof, который должен был возвращать метаданные по мемберу (аналог typeof(typename)), только для методов, свойств, событий, и полей). Типичные сценарии, который хотелось решить с его помощью — реализация INotifyPropertyChanged так, чтобы гарантировать корректное имя свойства в аргументах, и логгирование вызовов, чтобы гарантировать корректное имя текущего метода или свойства. В итоге вместо всемогущего инфуфа (реализация которого создаёт больше проблем, чем решает), прикрутили атрибут CallerMemberName, применяемый к параметрам
