The linked STL is a different Kokichi Sugihara illusion - by the same creator as this new class of illusions, and part of a body of work in this field that this appears to be a continuation of.
But it is. Those are objects that are mirror symmetric, and the apparent direction they're facing depends on viewing angle, creating the illusion that they haven't actually been mirrored.
It's still a useful generic exercise for beginners.
Although I recommend starting with a simpler syntax like sexpr, you can get more practice with less code.
For a deeper exercise, I recommend compiling to machine code instead of stopping at bytecode [1]; you can learn assembly along the way, which is more satisfying than compiling to C.
I agree that compiling to machine code is super satisfying, but there's a lot of upfront work you have to do before you can run your first "hello world": architectures, calling conventions, object file formats, linking.
That's why I no longer object to compiler tutorials stopping at assembly or even C, as long as the phases not present in interpreter tutorials like Bob Nystrom's brilliant one are non-trivial: type checking, optimizations, lowering.
Here's Martin Jacob's code to execute arbitrary memory. If you malloc a byte array and insert opcodes directly at indexes, you can construct machine code and execute it.
Since your C program is already in memory, you have access to the C standard library and don't have to worry about linking or object formats but you'll have to worry about parameter passing and FFI.
actually, our original windows programming in c course translated petsold's book into a course and all the punters hated it! i don't think it is a good book anyway, and i eventually got funding to completely re-write it, to good effect.
While writing a book is not particularly profitable, the author could probably earn more by self-publishing rather than working with a publisher, since the author has done most of the marketing anyway.
I think you are likely correct on this but I do think having deadlines helped me make sure I actually finished. If I was to write another I would self publish.
A good way to have deadlines is to presell the book, and promise these deadlines to people who paid. Example: buy now for 50% of the final price, two chapters already ready, and I promise one new chapter every two weeks.
I use this strategy, and I’m always amazed that people trust me enough to deliver as promised :)
Given the amount of high profile kickstarter failures (or delays), i'm surprised that people would continue to do pre-orders and such! I guess if the cost is small, it won't be a loss for the backer even if it was delayed.
I not only self publish but I print and warehouse my latest book and only sell it from my website. Still can't sell more than 2,000, but I cover my costs.
I think I made significantly more working with pragmatic bookshelf than I would have self publishing. That may be particular to pragmatic though, as they have a fairly loyal reader base.
Interesting! I wonder how big their read base is. Other commenters mentioned sales numbers around 2000, you must have made a far larger sale to compensate for the lower loyalty.
Is that really true? I would expect that going from IR to native code would be the hardest part because you have to worry about architecture and supporting different ISA’s. IR can be simple because it is abstract and hides lots of the dirty details of the hardware.
Generating code is not all that hard. Generating fast code is a challenge. Decoding instructions on some architectures is hard. If you have a nice general IR naively generating native code can be just a table lookup with a register tracking/allocation routine.
