SashaMercuryВы сравнили эти участки кода, и сделали следующий вывод
Мм.. это вывод в общем безотносительно этих участков кода. Скорее он объясняет, почему я ответил Вам именно этим примером.

SashaMercuryЯ же сравниваю их, и делаю следующий:
Код на Си оптимальней, так как
Саш, попробуйте на секунду остановиться и сформулировать: а что Вы вообще хотели доказать, вступая в дискуссию? Смотрите: изначально речь шла о круглых скобках. Потом - о красоте кода. Потом - об изобразительных возможностях. Теперь - об эффективности. Глядя на всё это, складывается ощущение, что Вы хотите доказать "лучше хоть чем-нибудь неважно чем".

SashaMercuryна каждой итерации цикла, мы делаем одну операцию чтения из потока, в случае аналогичного кода на языке Паскаль, чтение символа происходит дважды, на каждой итерации.
Вы здесь считаете абстрактных попугаев, что делает рассуждения бессмысленными. Просто представьте себе, что переменная C является полем объекта "поток", то есть паскалевский объект реализован примерно так:




Как видите, с одной стороны, все Ваши рассуждения про "два чтения" никуда не уходят, с другой стороны, выполняемые операции прямо-таки демонстративно одинаковы.

SashaMercuryПотому присваивание в условии цикла, я не могу назвать недостатком языка, это его преимущество.
Присваивание в условии никто и не называет недостатком языка. Недостатком дизайна библиотеки я назвал EOF как результат getc. Это влечёт за собой множество неудобств, начиная от int-результата и заканчивая тем, что fgetc таки может возвращать EOF как "очередной прочитанный символ из середины файла" и таки надо использовать feof(). А ещё, если мне не изменяет память, тот же EOF может возвращаться как индикатор ошибки, что делает ситуацию вообще бредовой.

SashaMercuryКод на Си, выполнится быстрее чем данный конкретный код на языке Паскаль?
Представления не имею. В своё время я наблюдал, как два очень крутых прога в течение нескольких лет соревновались "кто быстрее на той или иной задаче", как раз таки один писал на TP, другой на MC. В принципе, учитывая, что C дизайнился именно под максимальную эффективность, можно ожидать от него незначительно лучших результатов (незначительно - потому что основные траты всё равно пойдут на вызовы чтения в ОС). С другой стороны, я помню N случаев, когда Си неожиданно проседал из-за отсутствия какой-либо важной особенности. Скажем, довольно долго он не умел передавать параметры функций через регистры (а сейчас, кстати, умеет?)

Leonid Kudryavtsev1) у него сейчас как минимум inline ф-ции есть
Они у него есть очень давно, как и у Паскаля. Как и судя по всему уже достаточно давно есть fastcall, спасибо за подсказку.

JeStoneпри которых каждый разработчик (и только он) разрабатывает свою часть приложения,
Этот идиотизм надо было убить ещё лет сорок назад. Но, думаю, до окончательного его изживания я так и не доживу.

SashaMercuryдля меня очевидно, что он лучше во всём,
Так не бывает. Можно нежно любить свой бугатти вейрон, но таки для некоторых задач лучше подходит камаз, а для некоторых - велосипед.

При этом, нежно любя свой бугатти вейрон, стоит таки знать и понимать его недостатки. Скажем, если он сломается где-нибудь под Тюменью, будет достаточно проблематично найти запчасть.

SashaMercuryОчевидным решение проблемы определения конца файла будет возврат символа не принадлежащего пространству возможных элементов
Одно из важных качеств разработчика - умение выбирать лучшее решение, не останавливаясь на очевидном . Описанное Вами - давно известный путь в адъ. Почти все проходили это, засовывая всякие минус единицы в возраст и прочие "что никак не может встретиться". Потом приходят неанглоязычные пользователи, и вдруг оказывается, что виндовая буква "я" совершенно случайно равна EOF (char ведь у нас signed, мы помним, да?). Потом у нас приходит unicode, и вдруг оказывается, что в пространстве int16 перестаёт хватать места. Итдитп., и в итоге оказывается, что в библиотеку таки попадает feof(), потому что гениальной идеи "возврата символа не принадлежащего пространству" таки не хватает, чтобы прикрыть задницу.

maytonЭто участь особо крупных проектов. Неизбежно вобщем-то.
Это участь плохо управляемых проектов. Соглашусь с тем, что у "особо крупных" повышен риск оказаться "недостаточно хорошо управляемым", тем не менее, последствия вполне очевидны.

SashaMercuryсобственно, по этой причине, я и написал про субъективность мнений
А где Вы здесь видите субъективность? То, что на бугатти не стоит возить три тонны щебёнки - факт. То, что под Тюменью вряд ли есть для него запчасти - тоже факт. Субъективность в том, что "любить или не любить", но любовью не стоит закрывать факты. Собственно, любовь к бугатти проявится как раз в том, чтобы возить щебёнку на камазе :)

JeStoneЭто почему?
Потому что нетехнологично. Просто представьте себе, как товарищ Сталин говорит: хочу, чтобы в параде девятого мая принял участие наш новый бомбардировщик. А ему отвечают: не получится, потому что токарь дядя Вася ушёл в запой, а узел крепления элеронов у нас кроме него никто не вытачивает.

"Каждый ковыряет свою песочницу" - это типичная идея неуправляемого проекта, без общей идеологии, без общего стиля и без команды. Исход такого проекта немного предсказуем. А бытиё.... помню один анекдотический случай. В конторе, в которой к моменту моего прихода был принят такой стиль. Прихожу к человеку, ведавшему неким модулем. Говорю: хочу вот такую доработку. Он говорит: о, отличная мысль. Я говорю: я посмотрел, для этого надо добавить одну вот такую строчку вот сюда. Он: круто. Я говорю: когда будет готово? Он: где-то через месяц. Я: Ты охренел? Там же одна строчка, и это сэкономит мне дня три работы в том, что мне нужно сдать через неделю. Он: я сейчас занят приоритетной задачей в другом модуле, приходи через месяц. В итоге пол-дня бегал, пока выбил таки разрешение вставить в чужой модуль эту одну строчку. И ещё хорошо, что выбил.

maytonsoftwarer, давай другую крайность представим. Тебе дали доступа на модуль. Ты тихонько закоммитил...
... и тут началось!
А что началось-то? Ну максимум, кто-то потратит пять секунд времени, чтобы откатить мой коммит.

JeStoneДядю Васю за невозможность исполнения своих обязанностей и пьянство стоит уволить.
Верно. А работу стоит организовать так, чтобы пьянство одного дяди Васи не срывало появление бомбардировщика на параде.

JeStoneА что касается второго случая, то что вам мешало отправить pull request своему коллеге?
Если обратите внимание, я в точности это и сделал. Ну с той разницей, что лет на десять раньше, чем появилось такое понятие.

JeStoneЭто никак не конфликтует с концепцией разделения обязанностей по разработке различных модулей приложения.
Никак. Просто сама концепция конфликтует со здравым смыслом.