Crafting Interpreters VS CppCoreGuidelines

> If you’ve been relying on Markdown and occasionally fighting its quirks, AsciiDoc might be the structured, fully-featured alternative you didn’t know you needed.

No, I'm afraid it's the format I know I don't need. At least not for the kind of things I usually use markdown for.

Readme files, technical documentation, moderately complex websites with templating and rendering engines - markdown works just fine. Sometimes with a custom `|||warning\n...\n|||\n` thrown in to render something in a box with a red border.

I get that there's a market in the space occupied by TeX, Typst (underrated IMHO), and possibly MS Word or Quark Express (for non-techies). Libreoffice is great in theory but, again IMHO, "eh" in practice. That market is generating book-length documents with all the cross-references and other features that needs.

That said, Robert Nystrom of "Crafting Interpreters" managed this just fine with markdown and a few custom scripts: https://journal.stuffwithstuff.com/2020/04/05/crafting-craft... , https://github.com/munificent/craftinginterpreters/tree/mast... . This is how those famous 10x writers/programmers work, I guess.

Asciidoc is Markdown's big brother? I'll carry on playing with the little brother, thank you very much.

Also the whole page is an ad for their own editor tool. $9.99 per month so you don't need to use your own editor and unintuitive tools like (gasp!) the terminal.

Build an Interpreter (Chapter 14 on is written in C)

[3]: https://github.com/munificent/craftinginterpreters

The best resource for any amateur compiler writer is Bob Noystrom's Crafting Interpreters:

https://www.craftinginterpreters.com/

It is well paced, well illustrated, and demonstrates a very simple recursive descent parser, avoiding all the junk typically foisted on students.

I cannot recommend the book highly enough, I use it in my compilers class.

The license is here:

https://github.com/munificent/craftinginterpreters/blob/mast...

Though now that I look at it, I apparently completely forgot to specify how the images should be licensed. Oops.

It's not a big deal and I really appreciate you reading and writing about the book, but I would prefer to not have the images reused without attribution.

Lots of people have done implementations in other languages: https://github.com/munificent/craftinginterpreters/wiki/Lox-...

I did the first half in Clojure (in order to teach myself Clojure), worked just fine. I had to do a bit of translation but it's really not a lot.

Dumb idea? No way. Actually, I'm currently reading Crafting Interpreters which is exactly this. It's free to read online, if you wanted to check it out: https://www.craftinginterpreters.com/

Super fun book.

Build an Interpreter (Chapter 14 on is written in C)

I’m guessing you’ll have to work with the scopes in the resolver:

https://github.com/munificent/craftinginterpreters/blob/mast...

I've found both explicit future/promise management and coroutines difficult (even irritating) to reason about. Co-routines look simpler at the surface (than explicit future chaining), and so their the syntax is less atrocious, but there are nasty traps. For example:

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

I liked "Effective Modern C++" although that is a little bit out of date by now. Stroustrup's recent article "21st century C++" https://cacm.acm.org/blogcacm/21st-century-c/ . There are also the C++ core guidelines though maybe those are also out of date? https://github.com/isocpp/CppCoreGuidelines

I've been looking at Rust and it's an improvement over C, but it still strikes me as a work in progress, and its attitude is less paranoid than that of Ada. I'd at least like to see options to crank up the paranoia level. Maybe Ada itself will keep adapting too. Ada is clunky, but it is way more mature than Rust.

I haven't read much from Bjarne but this is refreshingly self-aware and paints a hopeful path to standardize around "the good parts" of C++.

As a C++ newbie I just don't understand the recommended path I'm supposed to follow, though. It seems to be a mix of "a book of guidelines" and "a package that shows you how you should be using those guidelines via implementation of their principles".

After some digging it looks like the guidebook is the "C++ Core Guidelines":

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

And that I should read it and then:

> use parts of the standard library and add a tiny library to make use of the guidelines convenient and efficient (the Guidelines Support Library, GSL).

Which seems to be this (at least Microsoft's implementation):

https://github.com/microsoft/GSL

And I'm left wondering, is this just how C++ is? Can't the language provide tooling for me to better adhere to its guidelines, bake in "blessed" features and deprecate what Bjarne calls, "the use of low-level, inefficient, and error-prone features"?

See this: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

Technically, headers are just copy-paste, obviously. However, there's value to keeping them as standalone as possible.

> close a file (which ironically is the poster child for RAII)

Yes, I call this "RAII is a lie" (T-shirt pending).

Closing file descriptors is univerally used to showcase RAII, but it should never be used for that.

C++ has the same problem:

https://github.com/isocpp/CppCoreGuidelines/issues/2203

In there, it is acknowledged that a manual Close() should always be provided, and used if you want guarantees.

> is a bad pattern

Good that Rust at least figured it out early that it's a bad pattern!

Never use RAII in situations where the cleanup can fail!

The standard library types are guaranteed to be in a useful state after being moved from (the term "valid state" is used for this). Of course, that doesn't mean that your own types have to, but the C++ Core Guidelines suggest doing so [1].

1: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

It’s in the cpp core guidelines: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

std::reference_wrapper still can’t save you from yourself, but its slightly better.

Slightly tongue in cheek answer: it is easy to write this kind of code in C++ without having C involved, hence style guides will usually have a prominent guideline specifically against this type of code[1].

In Rust, I think you only really run into this issue when interacting with C (or otherwise engaging in unsafe code), so for normal Rust coding it doesn't need to be spelled out as a guideline. And the Rustonomicon[2], the go-to resource for unsafe Rust, isn't really written as a set of guidelines. At least from a brief search, I found it harder to find a Rust page that specifically says "don't do this".

1: E.g. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines..., the first guideline in the "resource management" section.

2: https://doc.rust-lang.org/nomicon/intro.html