Hacker News Reader

Brian's choice to use C is perfectly well justified:

"I am thinking that we should choose C to implement our PL/0 compiler. Eventually we will want to have this compiler run on many different platforms, including Unix, MS-DOS, and potentially even CP/M. C is a language that will run on every platform I would want to run our PL/0 compiler on, so C works for me. C also requires no special setup so our usual development platform of vim on OpenBSD will work just fine. Finally, it will help with bootstrapping the self-hosting version of the PL/0 compiler, since we in theory could natively compile the C implementation on our target platform then use that to compile the PL/0 implementation, also on the target platform."

The reader may learn something from these posts whether they choose to write a compiler in C or not.

I don't mean to debate Brian's choice (your quote shows it does fall into my exception anyway) but mention to readers here why they may be more interested in following guides on compiling/interpreting implemented in other languages than C.

C is actually a huge disadvantage here for me, since I have no use for it outside of this tutorial which makes it hard to justify learning it on top of learning how a compiler works...

C is a simple language and at least used to be a language almost everyone knew.

I don’t know why they’re writing the parser using globals though instead of passing a pointer to a parser state struct.

C is an incredibly complex language, it just appears simple. It's simple to get started and incredibly hard to do correctly, like skiing.

No, those things are not a complexity of C. They're just complex to implement at a lower level. They're complicated in any language, often, if approached at the level C provides. You have to hand-hold the machine through it. A C-like implementation of linked lists in an array of memory using pointers, for example, looks just as bad if written in that way in unsafe {} Rust, or even some mutating thing in Haskell. You can do that if you want, but you don't have to. Those languages allow you to abstract that away very quickly (often already pre-abstracted for you with default approaches). That's what people mean when they say C is simple. Plain and simple. Minimal. You have to do much of the heavy lifting.

Respectfully disagree. A language that fails to adequately provide safeguards to a user is a complex language because it forces all the complexity of dealing with the underlying machine onto the user. These are things a user needs to know to be effective in the language, which in turn makes using the language complex. It's a deceptively simple language.

C is complex because of what it doesn't do, not what it does. That's IMO worse.

It's not so much that we're disagreeing as arguing different points about the language, I think. You are right that it is not a simple language to use, in many ways. Archaic, unnecessarily complicated to implement many standard approaches, and very repetitive. The header system is just the wrong approach. Etc. I wouldn't pick it for the main language for a new project, if at all avoidable personally.

It's very easy to implement, though. A compiler fits in 32 kilobytes of RAM on some architectures. Only a handful of control structures. Limited types. That's the sense of simple that I meant, and which most people meant. It's not a compliment. It's a neutral observation. It's actually C's greatest weakness. It's too simple.

I think we’re in violent agreement :)

C itself is not particularly complex, especially compared to other languages, like C++. It does have a ton of footguns and nasty UB things though.

But writing good, safe code in C can be very complex. That doesn't make the language itself is complex.

Parsers involve a lot of string processing, which is really inconvenient and easy to get wrong in C.

Well, only the lexer deals with strings, and even then… it’s not really creating strings, just extracting some information from them. Creating strings efficiently and safely is IMO the hard part of string management in C.

I don’t know why they’re writing the parser using globals though instead of passing a pointer to a parser state struct.

Because there's only one. Why obfuscate that fact? Don't be tempted by the cargo-cult to make things more complex than they need to be just to appease some dogmatic "best" practices that actually aren't.

I think this is a really good example to point to in discussions of ‘cargo-cult’-ing. GP is merely reciting the standard ‘best’ practice for development in C, and on a more complex project or in another use case, they may be correct to do so. However, as you pointed out, in this case the globals are true single instance ‘objects’ and the use is semantically sensible and justified. It dovetails nicely with some of the DoD vs ECS discussion from the front page earlier today. Do what makes the most sense for your use case for reasons that apply to your project, everything else is abstraction.

> The overhead to writing C makes it a less friendly introduction to the topic if you have never written a compiler or interpreter (or parser, specifically) before.

That's true and was my first thought. C seems like an arcane choice for an introduction course.

> But it's hard to understand the benefit to writing a language frontend in C, generally speaking.

The advantage of writing in C is that the language provides very little “high” level features. All you have is just functions and memory so you end up doing everything which is a laborious process but rewarding to the mind especially if you are someone who never did low level programming.