GCC Specs: An Introduction | Hacker News Reader

GCC Specs: An Introduction

wozniak.ca

128 pointstodsacerdoti20 comments

Everyone should take a lesson from this language about how not to design a DSL. It probably started out as a humble declarative language, but it got extremely complex after decades, with impurity (`%x` etc.) and functions (`%:foo()`) and a sort of metaprogramming. At some point the whole language should have been scrapped (with a minimal support for backward compatibility) and replaced with a small scripting language, preferably shared with other places that need scripting. Don't grow your language past its limit.

I agree. But hindsight is a very cushy position to look back from. Making said decision at any given point in time during the development is harder. Should I add a simple support for functions because I need to express something the DSL doesn’t support or should I replace everything and replace it with a complete new solution and added complexity. I mean these decisions tend to become very clear a few month/years down the line. The dangerous path of not doing a needed refactor early is that with added time, it can become more and more difficult to do the refactor at a later point. Could be because of sheer size, or because there are no test specs or because the feature is public facing.

I totally agree that you can't decide whether a refactoring is required or not for quite a long time. But this language has been around for more than 2 decades, and documented since 2001 [1]. Moreover all main issues were already present at that point and even more options and features were added since then (e.g. `%:sanitizer()` should have been added after sanitizers themselves, i.e. 2012). I think 21 years are long enough to do something about it.

[1] https://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#SEC18

Again no argument there. Don’t want to imply the intend of the parent comment but I hear it quite often at work that new people come into projects etc and declare statements backed by virtue of looking at all the facts long after all decisions had been made. I think with projects like GCC any decision should be waited for the long game. In commercial software the pesky labor and maintenance cost also become a factor :(

That's indeed a good point, as I too have been both culprit and victim of this issue. My general sentiment was that this is mostly about management, i.e. how to manage complexity, and this apparent failure can make a good counterexample, but I was not careful enough to put a disclaimer that GCC may have a totally good reason to leave it as is (if it's the case, the reason is probably that only a small number of people will ever work with this language). Thank you for explicitly voicing that concern.

I think the main mistake here is that it was made to be a public interface instead of an internal implementation detail. Now you can expect that some people are relying on custom specs. Migration to a saner configuration language is still possible, but it probably needs to be done with deprecating and phasing out the old DSL concurrently to introducing a new language. Bonus points for providing a tool for converting old specs to the new language.

> I think the main mistake here is that it was made to be a public interface instead of an internal implementation detail.

That's inevitable in my opinion, because this modular interface has been used for a very long time. You should be able to replace a compiler, C/C++ preprocessor, linker and assembler without altering the entry point, i.e. the driver. Each component may have multiple versions for each supported target as well. So the driver itself has to be configured in some way, and the result is this annoying language, which has to be publicly visible for distro maintainers for example.

By the way Clang also has a similar file format [1], even though it is considerably simpler possibly because Clang is not that modular by design. (This is AFAIK intentional.)

[1] https://clang.llvm.org/docs/UsersManual.html#configuration-f...

> That's inevitable in my opinion, because this modular interface has been used for a very long time.

I wonder how widely it's actually used and if making this an exposed modular interface was worth it.

Everybody should already know this! Look at CMake, Ant, most Linux tools etc.

All starting out as simple DSL’s and then evolving into really badly designed obscure and WTF generating programming languages.

C++ templates is another great example of this. It is the worse functional programming language ever invented. An absolute pile of garbage that every new standard is trying and failing to fix.

Bandwidth has been restricted on this URL. Archives are available at:

https://web.archive.org/web/20240103035219/https://wozniak.c...

https://archive.is/20240103045612/https://wozniak.ca/blog/20...

like writing sendmail.cf

claus assman anyone? i submitted a patch/ contribution to him once. he accepted it.

i also did have to write my own specs file, for what reason i forget

Not that Wozniak.

Geoff's articles have had quite a few big HN threads over the years: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

(but please don't post unsubstantive comments to Hacker News)

The parent is a refined version of https://news.ycombinator.com/item?id=8832967

I find interesting Wozniak being interested and sharing his thoughts about C compilers at 73.

Not sure if you're being facetious, but if not, different Wozniak :)

I genuinely thought it was the other one. I feel dumb for my naive bias.

Thanks for your honest mistake and the answers to it I was spared from making the same honest mistake.

Thanks for your sacrifice :-)

This is as good a time as any to link to "Falsehoods programmers believe about names"

https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...

Okay, good points. Now please encode this:

https://youtu.be/hNoS2BU6bbQ

Reply on news.ycombinator.com