Hacker News Reader

Comment by dunefox | Hacker News Reader

A shame that it uses C though, imo, instead of being language agnostic.

In the introduction (1.4. What language should I use?) - the author explains why he used C. Please read it.

I mean isn't C ubiquitous enough that it is essentially language agnostic? Or is your suggestion that is should be purely pseudocode?

Pseudocode can be easy to understand but you (also) need a real language to cement your understanding of the subject.

> you (also) need a real language to cement your understanding of the subject.

That's why I'd like to use a language that I already know instead of learning a new one while also learning new material.

Basic C is not that hard. Probably one of the easiest languages to get into.

Sure, but it’s a hard language to write good code in.

Well you can. If you understand the algorithm you can write it in any language you know. Additionally, C is at basic level just loops, conditionals and function calls so it will be easy to translate from it if you need to. And then there are other books using other languages out there and people can choose.

It is also manual memory management, lack of generics, of polymorphism, and what not else. Even C++ would be a better choice.

With C you need to pay attention to things like manual memory management which aren't necessary with other languages or to understand the material.

Manual memory management is optional. IIRC some version of the D compiler was written assuming an infinite virtual address space (basically they just did not bother calling free() ever)!

Is that why D is so prevalent among (some) quant shops?

There's a chapter in the book dedicated to memory layout of programs that discusses program segments, paging, implementation of malloc/free, etc that is more or less required before getting to the assembler and codegen stages.

Even if you can write a compiler assuming infinite memory that generates programs that also assume it, it would be a disservice to readers to ignore that for brevity. It's an important part of understanding how programs are created.

Aye but these lads are building a compiler. Probably shouldn't hide things like 'memory management' at the introduction stage as use of memory is inherent to all computing and programming.

Sure, that makes sense, but you can write a compiler in languages that don't require it themselves. That's what I meant.

> Sure, that makes sense, but you can write a compiler in languages that don't require it themselves.

I don't follow your rationale. With C the developer manages heap memory by basically calling malloc and free.

This means that once you have the memory model set, all you need to do to roll your compiler is to implement the interface.

A language that "don't require it themselves" is a language which provides only high level constructs and dumps all the memory management logic to the compiler/runtime, from object allocation/deallocation to lifetime management.

How is that simpler to pull off by a compiler writer?

The target language generally has nothing to do with the language of the compiler, where automatic memory management is just as useful (and also helps to minimize the amount of unrelated technical detail) as anywhere else.

Yes. Pseudocode is better for teaching than C. Plus, translating pseudocode into a language of choice is a good exercise.

Another good idea is to write a compiler in the target language.

> A shame that it uses C though, imo, instead of being language agnostic.

What did you have in mind?

Honestly, I think I'd prefer pseudocode that I can read to understand the idea and then work in my language of choice rather than C.

Psuedocode means ambiguity which means misunderstandings. As soon as you remove all ambiguity any Pseudocode just becomes a language.

Good point, although I think it should be doable when describing input and output well enough.

That's been delegated to the diagrams and algebra -- and there's also the usual english-psuedocode interspersed throughout the chapters (presumably more so on the theoretical chapters e.g. chapter 4)

> Honestly, I think I'd prefer pseudocode that I can read to understand the idea and then work in my language of choice rather than C.

What stops you from understanding the idea by reading C? It's a tried-and-true language whose K&R version fits entirely in an easy to read ~180pg book which has real world applications, unlike pseudocode.

C code is usually rife with unrelated technical detail like manual memory management. It also lacks ways to build useful abstractions that exist in other languages.

Agreed! I would have used ML faminly languages. Of course, that implies learning ML before reading the book whereas C is definitely known by more developers as it’s been in all of our courses

Sure, then it would be the same thing just with ML (which I pers. would prefer to C, but yeah). Pseudocode to explain the idea would be ideal, then you can work through the book in a familiar language.

C is fine, it's just not ideal for me to learn C which I have no use for and learn a new skill at the same time.

ML-like pseudocode would be much different from C-like or python-like pseudocode (e.g. heavy use of ADTs)

I think C is basically language agnostic, isn't it? Approximately everyone working at the level of a course on compilers knows C.

I don't know C and have no intention of learning it, so I'd prefer pseudocode that I can read without already knowing C or investing time into learning C just for this book.

I really struggle how someone can be ready to learn about compilers without already having enough context where they know C. If you know enough to be doing compilers, you can pick up C in 15 mins.

I don't know how this is difficult to imagine. I have no need for C and am interested in interpreters and compilers.

> have no need for C and am interested in interpreters and compilers

But you do have a need for it, because it’s the lingua franca of conversations about compilers and interpreters… as you’ve just found out with this course.

Like saying you want to work in the Vatican but you have no need for Latin.

> because it’s the lingua franca of conversations about compilers and interpreters

There are many materials, compilers, and interpreters that use ocaml and haskell, for example. C isn't the only one. That's why I'd prefer pseudo code instead of C, so that I could use this book without learning a specific language only for it.

I really don’t understand what you’re planning to do the first time someone says to ‘check the header file’ to understand how some system call works.

For that, you don't need to know C the language, but C the calling convention https://gankra.github.io/blah/c-isnt-a-language/

This doesn't make any sense. Even you knew the C calling convention, but not C, where are you going to get documentation for system calls that doesn't use C code? The Linux, macOS, etc documentation uses C.

Reading the headers and prototypes in the man pages doesn't require "knowing" C. You just need to know the very simple subset of C's syntactical rules and the calling conventions. Anyway, reading C is far easier than writing C, most popular languages use the same syntax and operators.

I don't know what that has to do with learning about compilers and interpreters.

> I don't know what that has to do with learning about compilers and interpreters.

Compilers and interpreters, unless they're running on bare metal, which is very niche, talk to the operating system using something called 'system calls' to ask for resources that they can't provide themselves, like virtual memory space and IO. These system calls are documented in C.

For example I wrote a Ruby compiler in Ruby, but I still need to know about the mmap system call, which is documented in C, to allocate my memory.

https://github.com/chrisseaton/rhizome/blob/main/doc/memory....

https://man7.org/linux/man-pages/man2/mmap.2.html

https://github.com/chrisseaton/rhizome/blob/main/lib/rhizome...

Now I can finally reply: that makes sense, and in hindsight is quite obvious, thanks. My general lack of knowledge in this area is a part of why I'd like to study it more, but preferably I'd like to use a language I'm already comfortable with. C is just very far removed from everything I have use for and am interested in.

> These system calls are documented in C.

Sure, but the compiler will still have to generate machine code for those.

Well, the author shouldn't have to potentially learn another language just to write a book on compilers and interpreters.

Maybe... MAYBE you don't have to read this book.

> Maybe... MAYBE you don't have to read this book.

Where did I say I have to read it or that the author should learn another language? Nowhere. I said I wish it wasn't using C so that I could read it more easily.

You will have to learn whatever it is you do not like about C anyway if you want to generate machine code.

Reply on news.ycombinator.com