![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
trurle Тута прислали мне ссылку на C++FQA, и должен сказать что я более чем впечатлился. Помимо стиля прямо фоменковского ( автору типа не нравятся классы в C++, гы ), этот текст демонстрирует прискорбное непонимание природы программирования как инженерной деятельности.
В основу C были положены следующие инженерные соображения:
Разумную критику языка C можно вести с двух позиций: либо эти инженерные компромиссы предполагаются порождающими средство разработки, не оптимальное для тех или иных задач, либо язык C далек от оптимального решения, заданного рамками требований. Обсуждать первую позицию довольно неинтересно, поскольку очевидно что есть масса проектов применение в которых языка C было вызвано соображениями не вполне инженерными. Что же касается второй позиции, насчет существования языка, удовлетворяющего упомянутым требованиям и превосходящего C, то, видимо, верно следующее: язык C достаточно близок к оптимуму что бы гипотетическое превосходство альтернативных языков не было способно перебить зависимость от пути: при наличии двух сравнимых языков программирования естественным преимуществом обладает более развитая среда разработки.
Далее, язык C++ был спроектирован и развивался так что бы сохранить все свойства языка C и добавить к нему объектно-ориентируемость. Это обстоятельство делает несодержательным подавляющую часть текста, содержащегося в C++FQA.
Вполне возможно что тем же критериям удовлетворял бы и иное расширение C; к примеру, жизнь была бы легче если бы в C++ не было множественного наследования и, напротив, был бы более развитый RTTI, не говоря уже о менее монструозных generics/templates. Однако эти недостатки, как и в случае с C, перебиваются наличием развитых сред разработки; можно утверждать что гипотетическое идеальное объектно-ориентированное расширение C не настолько лучше существующего реально C++ со всей его оболочкой что бы оправдать сколько-мибудь массовый переход на иной язык при решений задач для которых объектно-ориентированное расширение C является самым подходящим инструментом.
В основу C были положены следующие инженерные соображения:
- Язык должен быть компилируемым, то есть среда разработки должна на выходе производить бинарный файл с командами процессора, непосредственно исполняемыми аппаратурой целевого компьютера. Требование это вытекало из желания минимизировать потери производительности, возникающие при использовании языка, отличного от ассемблера; в дальнейшем коэволюция компиляторов и CPU привела к положению при котором написание на ассемблере кода, более производительного чем выдача компилятора, стало нетривиальной задачей.
- В языке должны быть примитивные тишы, совпадающие с аппаратно поддерживаемыми типами данных, в противном случае код, работающий с числами и символами, оказывается обременен излишним издержками
- Производные от примитивных типов структуры данных должны иметь тривиальное и эффективное отображение на команды процессора
- Операторы и прочие конструкции языка должны иметь тривиальное и эффективное отображение на команды процессора
- Все что возможно, должно быть отделено от языка и помещено в библиотеки
Разумную критику языка C можно вести с двух позиций: либо эти инженерные компромиссы предполагаются порождающими средство разработки, не оптимальное для тех или иных задач, либо язык C далек от оптимального решения, заданного рамками требований. Обсуждать первую позицию довольно неинтересно, поскольку очевидно что есть масса проектов применение в которых языка C было вызвано соображениями не вполне инженерными. Что же касается второй позиции, насчет существования языка, удовлетворяющего упомянутым требованиям и превосходящего C, то, видимо, верно следующее: язык C достаточно близок к оптимуму что бы гипотетическое превосходство альтернативных языков не было способно перебить зависимость от пути: при наличии двух сравнимых языков программирования естественным преимуществом обладает более развитая среда разработки.
Далее, язык C++ был спроектирован и развивался так что бы сохранить все свойства языка C и добавить к нему объектно-ориентируемость. Это обстоятельство делает несодержательным подавляющую часть текста, содержащегося в C++FQA.
Вполне возможно что тем же критериям удовлетворял бы и иное расширение C; к примеру, жизнь была бы легче если бы в C++ не было множественного наследования и, напротив, был бы более развитый RTTI, не говоря уже о менее монструозных generics/templates. Однако эти недостатки, как и в случае с C, перебиваются наличием развитых сред разработки; можно утверждать что гипотетическое идеальное объектно-ориентированное расширение C не настолько лучше существующего реально C++ со всей его оболочкой что бы оправдать сколько-мибудь массовый переход на иной язык при решений задач для которых объектно-ориентированное расширение C является самым подходящим инструментом.
