файлы используют цепочки headers как интерфейс, и в этих цепочках много нондетерминизма(ifdef) который зависит от последовательности включения этих файлов, которая может быть разной в отдельных файлах. Вся информация о проекте содержится только в сторонней системе сборки, Makefile.

Ещё эти headers почти всегда зависят от опций компилятора в командной строке, где определяются(-D) директивы препроцессора.
Каким будет код после препроцессора можно узнать только внутри компилятора и только как результат запуска сторонней системы сборки.
Вот и делай IDE. Есть и другие проблемы.
В IDE обычно хочется подсвечивать активные ветвления препроцессора(ifdef) и функцию показа точного кода который генерирует макрос. Нужно накапливать и сопоставлять по номерам строк большие объёмы данных. Опять же только как результат прогонки сторонней системы сборки.

Пузо!

Всё это может привести к некоторым решениям в Golang, почему типы лучше указывать после переменной, справа.

Скорость парсинга в C - меньшая из проблем, она вполне достаточна.

Другой эффект от этого, что можно избавиться от «правила спирали» сложных опеределений в C

В D избавились и без всей этой твоей паскалятины.

Почитать что в C sucks по их мнению, и в этом контексте сразу появляется Rust как одно из решений

Так вроде же их идеология заставляет отвергать любые языки сложнее Си.

Скорость парсинга не то что достаточна, с ней вообще никаких проблем. Тот же tcc летает не хуже паскаля, и это еще без главных оптимизаций - нужно использовать деревья, кроме оптимизаций больше там тормозить нечему. Чел просто несет феерическую чушь. gch понаделать можно тоже сколько угодно, различается только способ его подключения, а главные проблемы как были так и есть. Спасибо, еще одного расширения типа микрософтовского\аппловского #import мне не надо, пускай уж лучше стандарт допиливают, а пока остается как есть.

В D избавились и без всей этой твоей паскалятины.

В Dlang добавили паскалятины, как во все новые императивные языки.
Но сохранили синтаксические особенности C.

Например в D функцию без параметров можно вызывать без скобок:

fun; // вызов функции

Это не позволяет использовать имя функции в качестве указателя, что бы передавать как callback в другие функции.
Вместо этого используются delegate, структура из указателя на функцию и указателя на объект с которым работает эта функция(метод объекта по сути, который можно передавать).
Это есть в C#(одно из продолжений развития Pascal, но для маркетинга Microsoft оставилa брэндинг C), и в Dlang.
А сама идея, её развитие скорее из Oberon, type bound functions, функции привязанные к типам(объектам).
Во FreePascal и Delphi это есть очень давно, после функции указывается «of object».

type TOneArg = Procedure (Var X : integer) of object; 
var  
  oproc : TOneArg;

// пусть M какой экземпляр какогo-то класса
oproc:=@M.DoX;

В C# есть multicast делегаты, содержащие больше одного указателя на метод.

http://www.youtube.com/watch?v=expCgeQXqzA

Трудные времена для C...
Многие его пользователи не знакомы не только с другими языками, но не знают и сам C.

http://www.youtube.com/watch?v=GdxLLCzsx44

Да уж прям наитруднейшие, http://www.tiobe.com/tiobe-index/ Прям плачу, а ваш наверняка бы всем понравился и на первое место вышел. Ну а как иначе, он же «принципиальные» проблемы решает, как может не понравиться.

Ты как будто обиделся на что-то, и у тебя срабатывает защитный психологический рефлекс.

Но я знаю что означает индекс Tiobe, это как новость про «британские учёные доказали».

В Dlang добавили паскалятины, как во все новые императивные языки.

И от каких проблем Си они таким образом избавились?

Лучший комментарий треда

уточните кондицию

они против сосания (suckless), за сосание (suck unless), или чтобы сосать в меру (suck less)?

В Dlang добавили паскалятины, как во все новые императивные языки.
Но сохранили синтаксические особенности C.

Например в D функцию без параметров можно вызывать без скобок:

fun; // вызов функции

Это не позволяет использовать имя функции в качестве указателя, что бы передавать как callback в другие функции.

Все нормально в D с указателями на функцию. & надо добавить к имени.

auto funPtr = &fun; funPtr();

Вместо этого используются delegate, структура из указателя на функцию и указателя на объект с которым работает эта функция(метод объекта по сути, который можно передавать).
Это есть в C#(одно из продолжений развития Pascal, но для маркетинга Microsoft оставилa брэндинг C), и в Dlang.
А сама идея, её развитие скорее из Oberon, type bound functions, функции привязанные к типам(объектам).
Во FreePascal и Delphi это есть очень давно, после функции указывается «of object».

И функции и делегаты в D нормальные.

«of object» - позволяет только использовать метод класса в качестве делегата. В D - с любым контекстом.

будет плохо дружить со стандартом

Причем намеренно.

Другая проблема это синтаксис указателей. Вместо «*» лучше использовать «^»(circumflex).
При определении указателя ставить «^» в начале переменной. Для получения содержимого(dereferencing) ставить «^» после переменной.
Получение адреса переменной символом «@»(at) вместо «&».

Это с какого перепугу?

а поделки Suckless должны причинять боль пользователям

Каким пользователям? Этими поделками пользуются только авторы и парочка любителей экзотического BDSM.

http://git.suckless.org/scc/tree/cc1/stallman.msg

Что это за упорин? Это так одно из «преимуществ» scc над gcc выглядит?

Жаль фото не передаёт всю эту добрую дружескую атмосферу.

Зато аннотации докладов вполне себе:

simplicity and predictability are the primary objective over reckless efficiency and optimization

Чуваки не осилили «state-of-the-art research» и решили что это не они тупые, а все остальные неправильно компиляторы пишут.

theorizing a software system with a “text engine” at its kernel

Даже прототип слабать не смогли :)

the architecture of a Photoshop-like image editor is presented

Ржал в голос :-D

why self-bootstrappability is a bad idea in particular

Их недо-дистр не осилил bootstrap, но чуваков это не смутило - они тут же придумали объяснение, почему именно так и надо.

Восхитительные люди, этакий паноптикум из мира линукс.

Взял из «Прочти меня».

Smaller C is a simple and small single-pass C compiler, currently supporting most of the C language common between C89/ANSI C and C99 (minus some C89 and plus some C99 features).

«scc and qbe», представленный на конференции, и Smaller C, откуда вы процитировали кусочек документации, - два совершенно разных компилятора.

Currently it generates 16-bit and 32-bit 80386+ assembly code for NASM ...

Спасибо за NASM, но мне кажется, нужен всего то, только gas (GNU Assembler с его AT&T синтаксисом)!

Что касается GNU as, то подойдёт не любой, т.к. нужен генерящий ELF, а не COFF или ещё что-то (как в DJGPP, MinGW, CygWin), т.к. это единственный объектный формат, из которого собираются все возможные исполнимые файлы для DOS, Linux, Windows. В этом смысле у поддерживаемых NASM и YASM генерация ELF есть всегда. Более того, если нужно перенести Smaller C на другую систему (особенно, голую), проще перенести FASM, а не GNU as, NASM или YASM, т.к. не нужно тащить много библиотек и не нужно использовать распоследние фичи языка и массу скриптов или утилит во время сборки.